[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Internet Draft                                                J. Quittek
Document: draft-stiemerling-midcom-mib-00.txt             M. Stiemerling
Expires: April 2003                                      NEC Europe Ltd.
                                                            October 2003


       Definitions of Managed Objects for Middlebox Communication

                 <draft-stiemerling-midcom-mib-00.txt>

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026.  Internet-Drafts are
   working documents of the Internet Engineering Task Force (IETF), its
   areas, and its working groups.  Note that other groups may also
   distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   Distribution of this document is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Abstract

   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it describes a set of managed objects that allow
   configuring middleboxes, such as firewalls and network address
   translators, in order to enable communication across these devices.
   The definitions of managed objects in this documents follows closely
   the MIDCOM semantics defined in RFC XXXX.








Quittek, Stiemerling                                            [Page 1]


Internet-Draft                 MIDCOM MIB                   October 2003


Table of Contents

   1 Introduction .................................................    2
   2 The Internet-Standard Management Framework ...................    2
   3 Overview .....................................................    2
   3.1 Terminology ................................................    3
   4 Realizing the MIDCOM Protocol with SNMP ......................    3
   4.1 MIDCOM Sessions ............................................    3
   4.1.1 Authentication and Authorization .........................    4
   4.2 MIDCOM Transactions ........................................    4
   4.2.1 Asynchronous Transactions ................................    4
   4.2.2 Configuration Transactions ...............................    6
   4.2.3 Configuration Transactions ...............................    8
   4.2.4 Atomicity or Transactions ................................   10
   4.2.4.1 Asynchronous Transactions ..............................   10
   4.2.4.2 Session Establishment and Termination Transactions .....   10
   4.2.4.3 Monitoring Transactions ................................   10
   4.2.4.4 Lifetime Change Transactions ...........................   11
   4.2.4.5 Transactions Establishing New Policy Rules .............   11
   4.2.5 Access Control ...........................................   11
   4.3 Access Control Policies ....................................   11
   5 Structure of the MIB module ..................................   12
   5.1 midcomCapabilities .........................................   12
   5.2 midcomSessionTable .........................................   13
   5.3 midcomRuleTable ............................................   14
   5.4 midcomGroupTable ...........................................   16
   5.5 midcomEvent ................................................   17
   6 Definitions ..................................................   17
   7 Usage Examples ...............................................   42
   7.1 Session Establishment (SE) .................................   43
   7.2 Session Termination (ST) ...................................   44
   7.3 Asynchronous Session Termination (AST) .....................   44
   7.4 Policy Reserve Rule (PRR) ..................................   44
   7.5 Policy Enable Rule (PER) after PRR .........................   45
   7.6 Policy Enable Rule (PER) without previous PRR ..............   46
   7.7 Policy Rule Lifetime Change (RLC) ..........................   47
   7.8 Policy Rule List (PRL) .....................................   47
   7.9 Policy Rule Status (PRS) ...................................   47
   7.10 Asynchronous Policy Rule Event (ARE) ......................   47
   7.11 Group Lifetime Change (GLC) ...............................   48
   7.12 Group List (GL) ...........................................   48
   7.13 Group Status (GS) .........................................   48
   7.14 Using Notifications For Negative Replies Only .............   48
   7.15 Not Using Notifications For Replies .......................   48
   8 Security Considerations ......................................   49
   9 Open Issues ..................................................   49
   10 Normative References ........................................   49
   11 Informative References ......................................   50
   12 Authors' Addresses ..........................................   51
   13 Full Copyright Statement ....................................   51


Quittek, Stiemerling                                            [Page 2]


Internet-Draft                 MIDCOM MIB                   October 2003


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
   monitoring of running instances of robust header compression.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in RFC
   2119 [RFC2119].


2.  The Internet-Standard Management Framework

   For a detailed overview of the documents that describe the current
   Internet-Standard Management Framework, please refer to section 7 of
   RFC 3410 [RFC3410].

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  MIB objects are generally
   accessed through the Simple Network Management Protocol (SNMP).
   Objects in the MIB are defined using the mechanisms defined in the
   Structure of Management Information (SMI).  This memo specifies a MIB
   module that is compliant to the SMIv2, which is described in STD 58,
   RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
   [RFC2580].


3.  Overview

   The managed objects defined in this document serve for controlling
   firewalls and Network Address Translators (NATs).  As defined in
   [RFC3234], firewalls and NATs belong to the group of middleboxes.  A
   middlebox is a device on the datagram path between source and
   destination, which performs other functions than just IP routing.  As
   outlined in [RFC3303], firewalls and NATs are potential obstacles to
   packet streams, for example if dynamically negotiated UDP or TCP port
   numbers are used, as in many peer-to-peer communication applications.

   As one possible solution for this problem, the IETF MIDCOM working
   group defined a framework [RFC3303], requirements [RFC3304] and
   protocol semantics [RFCXXXX] for communication between applications
   and middleboxes acting as firewalls, NATs or a combination of both.

   The managed objects defined in this document can be used for
   dynamically configuring middleboxes on the datagram path in order to
   enable datagram streams to pass the middlebox.  This way,
   applications can request pinholes at firewalls and address bindings
   at NATs.


Quittek, Stiemerling                                            [Page 3]


Internet-Draft                 MIDCOM MIB                   October 2003


   Since firewalls and NATs are critical devices concerning network
   security, security issues of middlebox communication need to be
   considered very carefully.

3.1.  Terminology

   The terminology used in this document is fully aligned with the
   terminology defined in [RFCXXXX].

   There is a conflict between the MIDCOM terminology and the SNMP
   terminology.  The roles of entities participating in SNMP
   communication are called 'manager' and 'agent' with the agent acting
   as server for requests from the manager. This use of the term 'agent'
   is different to its use in the MIDCOM framework: The SNMP manager
   corresponds to the MIDCOM agent and the SNMP agent corresponds to the
   MIDCOM middlebox.  In order to avoid confusion, the term agent is
   only used in combination with a prefix: either as MIDCOM agent or as
   SNMP agent.

   As also mentioned in RFCXXXX, please note that ... bindings!!


4.  Realizing the MIDCOM Protocol with SNMP

   In order to realize middlebox communication as described in RFC XXXX,
   several aspects and properties of the MIDCOM protocol need to be
   mapped to SNMP capabilities and expressed in terms of the Structure
   of Management Information version 2 (SMIv2).

   Basic concepts to be mapped are MIDCOM sessions and MIDCOM
   transactions.  For both, access control policies need to be
   supported.

4.1.  MIDCOM Sessions

   SNMP has no direct support for sessions. Therefore, they need to be
   modeled.  A session is stateful and has a context that is valid for
   several transactions.  For SNMP, a context is valid for a single
   transaction only, for example covering just a single request/reply
   pair of messages.

   Properties of sessions that are utlized by the MIDCOM semantics and
   not avaiable in SNMP need to be modeled.  Particularly, the middlebox
   needs to be able to send notification messages to agents
   participating in a session.

   The midcomSessionTable described in more detail in Section 5.1
   provides this information.  Each MIDCOM agent that opens a session
   has to create an entry in the midcomSessionTable.  This entry
   identifies the MIDCOM agent as participant of a session and gives the


Quittek, Stiemerling                                            [Page 4]


Internet-Draft                 MIDCOM MIB                   October 2003


   middlebox sufficient information for sending notifications.  The
   MIDCOM-MIB module requires a MIDCOM agent to create an entry in the
   midcomSessionTable before it creates or modifies MIDCOM policy rules.
   Without creating an entry in the session table, the MIDCOM agent
   cannot access any MIDCOM policy rule and it will not receive any
   notification indicating state changes at the middlebox.

4.1.1.  Authentication and Authorization

   MIDCOM sessions are required to provide authentication, authorization
   and encryption for messages exchanged between MIDCOM agent and
   middlebox.  SNMPv3 provides these features on a per-message basis
   instead of a per-session basis.  This more fine-grained security
   based on the User-based Security Model (USM, [RFC3414]) providing
   authentication and the View-based Access control Model (VACM,
   [RFC3415]) that can be used for authorization of access to managed
   objects.  This can be considered as overhead compared to per-session
   security mechanisms, but it completely satisfies the security
   requirements of middlebox communication.

   Any MIDCOM agent that wants to start a session by creating an entry
   in the session table needs to authenticate itself as an SNMP user.
   For the authenticated user, access rights must be given as part of
   the VACM configuration of the SNMP agent.

4.2.  MIDCOM Transactions

   RFCXXXX defines the MIDCOM protocol semantics in terms of
   transactions and transaction parameters.  Transactions are grouped
   into request-reply transactions and asynchronous transactions.

   SNMP offers simple transactions that in general cannot be mapped ono-
   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 a and
   request-reply transactions.  Within the set of request-reply
   transactions we distinguish configuration transactions and monitoring
   transactions, because they are implemented in slightly different ways
   by using SNMP transactions.

4.2.1.  Asynchronous Transactions

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





Quittek, Stiemerling                                            [Page 5]


Internet-Draft                 MIDCOM MIB                   October 2003


               +--------------+  notification +------------+
               | MIDCOM agent |<--------------| middlebox  |
               +--------------+    message    +------------+

                      MIDCOM asynchronous transaction


               +--------------+      SNMP     +------------+
               | SNMP manager |<--------------| SNMP agent |
               +--------------+  notification +------------+

             Implementation of MIDCOM asynchronous transaction


                 Figure 1: MIDCOM asynchronous transaction
                        mapped to SNMP notification


   One of the parameters is the transaction identifier that should be
   unique per middlebox.  It does not have to be unique for all
   notifications sent by the particular SNMP agent, but for all sent
   notifications that are defined by the MIDCOM MIB module.

4.2.2.  Configuration Transactions

   All request-reply transactions contain a request message, a reply
   message and potentially also a set of notifications.  In general they
   cannot be modeled by just having one SNMP message per MIDCOM message,
   because some of the MIDCOM messages carry a large set of parameters
   that do not necessarily fit into an SNMP message consisting of a
   single UDP packet only.

   For configuration transactions the MIDCOM request message can be
   modeled by one or more SNMP set transactions.  The action of sending
   the MIDCOM request to the middlebox if realized by writing the
   parameters contained in the message to managed objects at the SNMP
   agent.  If necessary, the SNMP set transaction includes creating
   these managed objects.  If not all parameters of the MIDCOM request
   message can be set by a single SNMP set transaction, then more than
   one set transactions are used, see Figure 2.  The last one of these
   messages must clearly indicate that now all parameters are set and
   that processing of the MIDCOM request message can start at the
   middlebox.









Quittek, Stiemerling                                            [Page 6]


Internet-Draft                 MIDCOM MIB                   October 2003


               +--------------+    request    +------------+
               | MIDCOM agent |-------------->| middlebox  |
               +--------------+    message    +------------+

                          MIDCOM request message


               +--------------+               +------------+
               |              |    SNMP set   |            |
               |              |-------------->|            |
               |              |    message    |            |
               |              |               |            |
               |              |    SNMP set   |            |
               |              |<--------------|            |
               |              | reply message |            |
               | SNMP manager |               | SNMP agent |
               |              |    SNMP set   |            |
               |              |- - - - - - - >|            |
               |              |    message    |            |
               |              |               |            |
               |              |    SNMP set   |            |
               |              |< - - - - - - -|            |
               |              | reply message |            |
               |              |               |            |
               |              |  . . .        |            |
               +--------------+               +------------+

                 Implementation of MIDCOM request message
                     by one or more SNMP set messages


                     Figure 2: MIDCOM request message
                      mapped to SNMP set transactions


   Please note that a single SNMP set transaction consists of an SNMP
   set request message and an SNMP set reply message.  Both are sent as
   unreliable UDP packets and may be dropped before they reach their
   destination.  If the SNMP set request message is lost, then the SNMP
   agent repeats the message after receiving no reply for a specified
   time.  Also if the SNMP set reply message is lost, the SNMP agent
   retransmit the SNMP set message. But this time, the SNMP agent
   receives the same message twice and must make sure that it accepts
   the second message as it did the first one and that it sends an SNMP
   reply message again.

   The MIDCOM reply message can be modeled by an SNMP norification
   transaction optionally followed by one or more SNMP get transactions
   as shown in Figure 3.  The SNMP agent informs the SNMP manager about
   the end of processing the request by sending an SNMP notification.


Quittek, Stiemerling                                            [Page 7]


Internet-Draft                 MIDCOM MIB                   October 2003


   If possible, the SNMP notification carries all reply parameters.  If
   this is not possible, then the SNMP manager has to perform additional
   SNMP get transactions as long as is needed to receive all of the
   reply parameters.


               +--------------+     reply     +------------+
               | MIDCOM agent |<--------------| middlebox  |
               +--------------+    message    +------------+

                           MIDCOM reply message


               +--------------+               +------------+
               |              |     SNMP      |            |
               |              |<--------------|            |
               |              |  notification |            |
               |              |               |            |
               |              |    SNMP get   |            |
               |              |-------------->|            |
               |              |    message    |            |
               | SNMP manager |               | SNMP agent |
               |              |    SNMP get   |            |
               |              |<--------------|            |
               |              | reply message |            |
               |              |               |            |
               |              |    SNMP get   |            |
               |              |- - - - - - - >|            |
               |              |    message    |            |
               |              |               |            |
               |              |    SNMP get   |            |
               |              |< - - - - - - -|            |
               |              | reply message |            |
               |              |               |            |
               |              |  . . .        |            |
               +--------------+               +------------+

                  Implementation of MIDCOM reply message
                          by an SNMP notification
                     and one or more SNMP set messages


                      Figure 3: MIDCOM reply message
         mapped to SNMP notification and optional get transactions

4.2.3.  Configuration 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 agent wants to


Quittek, Stiemerling                                            [Page 8]


Internet-Draft                 MIDCOM MIB                   October 2003


   retrieve.

   Since monitoring is the stronghold 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.  If one or more SNMP get transactions are
   required depends on the amount of information that is to be
   retrieved.


               +--------------+    request    +------------+
               |              |-------------->|            |
               |              |    message    |            |
               | MIDCOM agent |               | 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 4: MIDCOM monitoring transaction
                      mapped to SNMP get transactions



Quittek, Stiemerling                                            [Page 9]


Internet-Draft                 MIDCOM MIB                   October 2003


4.2.4.  Atomicity or Transactions

   Given the realizations of MIDCOM transactions by means of SNMP
   transactions, atomicity of the MIDCOM transactions is not guaranteed
   anymore.  Therefore, we analyze the potential loss of atomicity for
   each MIDCOM transaction.

4.2.4.1.  Asynchronous Transactions

   There are two asynchronous MIDCOM transactions: Asynchronous Session
   Termination (AST) and Asynchronous policy Rule Event (ARE).  For both
   atomicity is maintained, because each of them is modeled by a single
   atomic SNMP notification transaction.

4.2.4.2.  Session Establishment and Termination Transactions

   For the Session Establishment (SE) transaction and the Session
   Termination (ST) atomicity is maintained.  The ST transaction has
   very few parameters.  The request parameters can be transmitted by a
   single SNMP set request message and the reply parameters can be
   transmitted by a single SNMP notifications message.

   Basically, the same holds for SE, but it needs more explanations.
   The SE transaction include the optional transmission of
   authentication challenges and authentication replies.  These are not
   required if SNMPv3 is used, because SNMPv3 provides all required
   means for authentication.  Also, the SE transaction includes
   tranmission of middlebox capabilities from the middlebox to the
   agent.  But for this transmission, there is no atomicity requirement,
   because these capabilities are static and can be transmitted piece by
   piece.

   Therefore, the SE transaction is implemented by an SNMP set
   transaction modeling the request message and an SNMP notification
   transaction modeling the reply message excluding the transfer of
   middlebox capabilities.  In the MIDCOM MIB module the middlebox
   capabilities are provided by a set of managed objects that can be
   read by the MIDCOM agent at any time using SNMP get transactions.

4.2.4.3.  Monitoring Transactions

   For the monitoring transactions Policy Rule List (PRL), Policy Rule
   Status (PRS) Group List (GL) und Group Status (GS) atomicity is not
   given anymore, because they are implemented by potentially more than
   one SNMP get operations.  The potential problem is that while the
   monitoring transaction is performed, the monitored items may change.
   For example, while reading a long list of policies, new policies may
   be added and already read policies may be deleted.  This is not in
   line with the protcol semantics.  However, it is acceptable because
   it i not in conflict with the MIDCOM requirement requesting the


Quittek, Stiemerling                                           [Page 10]


Internet-Draft                 MIDCOM MIB                   October 2003


   middlebox state to be stable and known by the MIDCOM agent, because
   the middlebox notifies the MIDCOM agent on all changes to its state
   that are performed during the monitoring transaction by sending
   notifications.  The MIDCOM agent 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 agent will finally know
   the state of the middlebox.

4.2.4.4.  Lifetime Change Transactions

   For the policy Rule Lifetime Change (RLC) transaction and the Group
   Lifetime Change (GLC) transaction atomicity is maintained.  They both
   have very few parameters for request message and reply message.  The
   request parameters can be transmitted by a single SNMP set request
   message and the reply parameters can be transmitted by a single SNMP
   notifications message.

4.2.4.5.  Transactions Establishing New Policy Rules

   To be done: Discuss atomicity of PRR and PER.

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 agent to the middlebox.

   For each transaction, the MIDCOM agent has to authenticate itself as
   an SNMP user according to USM.  Then the user's access rights to all
   resources affected by the transaction are checked.  Access right
   control is realized by configuring the VACM mechanisms at the SNMP
   agent.

4.3.  Access Control Policies

   Potentially, a middlebox has to control access for a large set of
   agents and to a large set of policy rules configuring firewall
   pinholes and NAT bindings.  Therefore it can be beneficial to use
   access control policies for specifying access control rules.
   Generating, provisioning and managing these policies is out of scope
   of this MIB module.

   However, if such access control policy system is used, then the SNMP
   agent acts as policy enforcement point.  An access control policy
   system must transform all active policies into configurations of the
   SNMP agent's User Based Security Model (USM) and the View-based
   Access Control Model (VACM).

   The mechanisms of USM allow an access control policy system to


Quittek, Stiemerling                                           [Page 11]


Internet-Draft                 MIDCOM MIB                   October 2003


   enforce MIDCOM agent authentication rules and general access control
   of MIDCOM agents to middlebox control.

   The mechanisms of VACM can be used to enforce access control of
   authenticated agents to MIDCOM policy rules based on the concept of
   ownership.  For example, an access control policy can specify that
   MIDCOM policy rules owned by user A, cannot be accessed at all by
   user B, can be read by user C, and can be read and modified by user
   D.

   Further access control policies can control access to concrete
   middlebox resources.  These are enforces, when a MIDCOM request is
   processed.  For example an authenticated MIDCOM agent may be
   authorized to request new MIDCOM policies to be established, but only
   for certain IP address ranges.  The enforcement of this kind of
   policies cannot be realized by using available SNMP mechanisms, but
   needs to be performed by the individual MIB module implementation.


5.  Structure of the MIB module

   This section presents the structure of the MIB module that is
   specified in Section 5.  The MIB is structured strictly according to
   the MIDCOM semantics described in [RFCXXXX].

   The MIDCOM semantics definition is structured into three major
   sections: session control, policy rule control and policy rule group
   control.  Accordingly, the MIDCOM MIB module contains three tables:
   the midcomSessionTable, the midcomRuleTable and the midcomGroupTable.
   Additionally, a set of scalar managed objects describe the middlebox
   capabilities.

5.1.  midcomCapabilities

   Information on middlebox capabilites is provided by the
   midcomCapabilities group of managed objects.  The following objects
   are defined:

    o   midcomCapabFirewall
        This is a boolean object indicating whether or not the middlebox
        acts as firewall.

    o   midcomCapabNat
        This is a boolean object indicating whether or not the middlebox
        acts as network address translator.

    o   midcomCapabPortTranslation
        This is a boolean object indicating whether or not the middlebox
        is capable of performing port translation.



Quittek, Stiemerling                                           [Page 12]


Internet-Draft                 MIDCOM MIB                   October 2003


    o   midcomCapabProtocolTranslation
        This is a boolean object indicating whether or not the middlebox
        is capable of performing protocol translation.

    o   midcomCapabTwiceNat
        This is a boolean object indicating whether or not the middlebox
        acts twice-NAT.

    o   midcomCapabInsideIpVersions
        This objects lists the IP versions available at the inside of
        the middlebox.

    o   midcomCapabOutsideIpVersions
        This objects lists the IP versions available at the outside of
        the middlebox.

    o   midcomCapabInsideWildcards
        This is a boolean object indicating whether or not the middlebox
        is capable of performing IP address wildcarding at the inside.

    o   midcomCapabOutsideWildcards
        This is a boolean object indicating whether or not the middlebox
        is capable of performing IP address wildcarding at the outside.

    o   midcomCapabPortWildcards
        This is a boolean object indicating whether or not the middlebox
        is capable of performing wilcarding of port numbers.

    o   midcomCapabPersistentRules
        This is a boolean object indicating whether or not the middlebox
        is capable of storing policy rules persistently.

    o   midcomCapabMaxLifetime
        This object indicates the maximum lifetime that this middlebox
        allows policy rules to have.

5.2.  midcomSessionTable

   The midcomSessionTable models MIDCOM sessions.  For opening a
   session, a MIDCOM agent has to create a row in this table.

   Without an entry in the midcomSessionTable, no policy rules can be
   established.  New entries in the midcomRuleTable are created by
   writing to the object called midcomSessionCreateRule in the
   midcomSessionTable.  The MIDCOM agent can specify the group
   membership and the default rule storage time of created enties in the
   midcomRuleTable by setting the corresponding objects in the
   midcomSessionTable.

   The midcomSessionTable is indexed by the SNMP user name of the


Quittek, Stiemerling                                           [Page 13]


Internet-Draft                 MIDCOM MIB                   October 2003


   authenticated MIDCOM agent.

   In particular, the midcomSessionTable contains the following objects:

    o   midcomSessionOwner
        This string indicated the user that created and owns the
        session.  It is the index of this table.  All policy rules (and
        policy rule groups) have the same owner as the corresponding
        entry in the midcomSessionTable from which they were created.

    o   midcomSessionIndex
        An index that serves for distiguishing different sessions of the
        same midcomSessionOwner.

    o   midcomSessionRuleGroupIndex
        The group to which policy rules created from the same session
        should be a member of.

    o   midcomSessionRuleStorageTime
        The default time policy rules created from the same session
        should be stored in the midcomPolicyTable after they are
        terminated.

    o   midcomSessionRuleIndexNext
        An object that can be read for obtaining an object identifier
        pointing to a so far not exsiting entry in the midcomRuleTable.

    o   midcomSessionCreateRule
        Writing a value read from midcomSessionRuleIndexNext to this
        object creates a new entry in the midcomRuleTable.

    o   midcomSessionStorageType
        This object indicates whether or not the session is volatile,
        non-volatile, or permanent.  Depending on the MIDCOM MIB
        implementation this object may be writable.

    o   midcomSessionRowStatus
        Writing to this object creates or deletes a row in the
        midcomSessionTable, i.e. it opens or terminates a session,
        respectively.

5.3.  midcomRuleTable

   The midcomRuleTable contains information about policy rules including
   policy rules to be established, policy rules for which establishing
   failed, establishe policy rules and terminated policy rules.

   Entries in this table are indexed by the combination of a
   midcomSessioOwner, a midcomGroupIndex and a midcomRuleIndex.  The
   midcomSessionOwner is the owner of the session from which the entry


Quittek, Stiemerling                                           [Page 14]


Internet-Draft                 MIDCOM MIB                   October 2003


   was created, the midcomGroupIndex is the index of the group of which
   the policy rule is a member.

   Entries in this table can only be created by writing to
   midcomSessionCreateRule in the midcomSessionTable.  Entries are
   removed, when their midcomRuleLifetime and midcomRuleStorageTime are
   timed out by counting down to 0.  A MIDCOM agent can explicitly
   remove an entry by setting midcomRuleLifetime and
   midcomRuleStorageTime to 0.

   The table contains the following objects:

    o   midcomRuleIndex
        The index of this entry must be unique in combination with the
        midcomSessionOwner and the midcomGroupindex of the entry.

    o   midcomRuleAdminStatus
        For establishing a new policy rule, a set of objects in this
        entry needs to be written first.  These objects are the request
        parameters.  Then, by writing either reserved(1) or enabled(2)
        to this object, the MIDCOM MIB implementation starts processing
        the parameters and tries to establish the specified policy rule.

    o   midcomRuleOperStatus
        This read-only object indicates the current status of the entry.
        The entry may have an initializing state, it may have a
        transient state while processing requests, it may have an error
        state after a request was rejected, it may have a state where a
        policy rule is established, or it may have a terminated state.

    o   midcomRuleStorageType
        This object indicates whether or not the policy rule is stored
        as volatile, non-volatile, or permanent.  Depending on the
        MIDCOM MIB implementation this object may be writable.

    o   midcomRuleStorageTime
        This object indicates how long the entry will still exist after
        entering an error state or a termiantion state.

    o   midcomRuleError
        This object is a string indicating the reason for entering an
        error state.

    o   midcomRuleNatService
        This object indicates which kind of NAT service is requested or
        established, respectively.  Possible NAT services are
        traditional NAT and twice-NAT.

    o   midcomRuleTransportProtocol
        This object indicates a transport protocol for which a policy


Quittek, Stiemerling                                           [Page 15]


Internet-Draft                 MIDCOM MIB                   October 2003


        reserve rule or policy enable rule was requested or established,
        respectively.

    o   midcomRulePortRange
        This object indicates a port ramnge for which a policy reserve
        rule or policy enable rule was requested or established,
        respectively.

    o   midcomRulePortParity
        This object indicates a port parity for which a policy reserve
        rule or policy enable rule was requested or established,
        respectively.

    o   midcomRuleFlowDirection
        This object indicates a flow direction for which a policy enable
        rule was requested or established, respectively.

    o   midcomRuleLifetime
        This object indicates the reamining lifetime of an established
        policy rule.  The MIDCOM agent can change the remaining lifetime
        by writing to it.

   Beyond the listed objects, the table contains 14 further objects
   describing address parameters. They include the IP version, IP
   address and port number for the internal address (A0), inside address
   (A1), outside address (A2) and external address (A3) and they include
   interface numbers for A1 and A2.  These objects serve as parameters
   specifying a request or an established policy, respectively.

5.4.  midcomGroupTable

   The midcomGroupTable has an entry per existing polcy rule group.
   Entries of this table are created automatically when creating 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 agent.

   Entries are indexed by the midcomSessionOwner of the session from
   which the policies belonging to the group where created.

   an entry of the table contains the following objects:

    o   midcomGroupIndex
        The index of this entry must be unique in combination with the
        midcomSessionOwner of the entry.

    o   midcomGroupLifetime
        This object indicates the maximum of the reamining lifetimes of
        all established policy rules that are members of the group.  The


Quittek, Stiemerling                                           [Page 16]


Internet-Draft                 MIDCOM MIB                   October 2003


        MIDCOM agent can change the remaining lifetime of all member
        policies by writing to this object.

5.5.  midcomEvent

   To be done: description of midcomSessionTermination,
   midcomRuleEvent, midcomGroupEvent.


6.  Definitions

   MIDCOM-MIB DEFINITIONS ::= BEGIN

   IMPORTS
       MODULE-IDENTITY, OBJECT-TYPE,
       NOTIFICATION-TYPE, Unsigned32, mib-2
           FROM SNMPv2-SMI                  -- RFC2578

       TruthValue, StorageType, RowStatus,
       TimeInterval
           FROM SNMPv2-TC                   -- RFC2579

       MODULE-COMPLIANCE, OBJECT-GROUP
           FROM SNMPv2-CONF                 -- RFC2580

       SnmpAdminString
           FROM SNMP-FRAMEWORK-MIB          -- RFC3411

       InetAddressType, InetAddress,
       InetPortNumber
           FROM INET-ADDRESS-MIB            -- RFC 3291

       InterfaceIndex
           FROM IF-MIB;                     -- RFC2863

   midcomMIB MODULE-IDENTITY
       LAST-UPDATED "200310070333Z"  -- October 07, 2003
       ORGANIZATION "IETF Middlebox Communication Working Group"
       CONTACT-INFO
          "WG charter:
             http://www.ietf.org/html.charters/midcom-charter.html

           Mailing Lists:
             General Discussion: midcom@ietf.org
             To Subscribe: midcom-request@ietf.org
             In Body: subscribe your_email_address

           Editor:
             Martin Stiemerling
             NEC Europe Ltd.


Quittek, Stiemerling                                           [Page 17]


Internet-Draft                 MIDCOM MIB                   October 2003


             Network Laboratories
             Kurfuersten-Anlage 36
             69221 Heidelberg
             Germany
             Tel: +49 6221 90511-13
             Email: stiemerling@ccrle.nec.de"
       DESCRIPTION
           "This MIB module defines a set of basic objects for
            configuring middleboxes, such as firewalls and network
            address translators, in order to enable communication
            across these devices.

            There are four groups of managed objects defined
            by this MIB module:
              - objects describing middlebox capabilities
                in the midcomCapabilities group,
              - objects modeling MIDCOM sessions in the
                midcomSessionTable
              - objects modeling MIDCOM policy rules in the
                midcomRuleTable
              - objects modeling MIDCOM polcy rule groups in the
                midcomGroupTable

            Copyright (C) The Internet Society (2003).  This version
            of this MIB module is part of RFC yyyy;  see the RFC
            itself for full legal notices."
   -- RFC Ed.: replace yyyy with actual RFC number & remove this notice

       REVISION    "200310070333Z"  -- October 07, 2003
       DESCRIPTION "Initial version, published as RFC yyyy."
   -- RFC Ed.: replace yyyy with actual RFC number & remove this notice

       ::= { mib-2 4444 }
   -- 4444 to be assigned by IANA.

   --
   -- main components of this MIB module
   --

   midcomObjects       OBJECT IDENTIFIER ::= { midcomMIB 1 }
   midcomNotifications OBJECT IDENTIFIER ::= { midcomMIB 2 }
   midcomConformance   OBJECT IDENTIFIER ::= { midcomMIB 3 }


   --
   -- Capabilities group
   --
   -- The MIDCOM capabilities group contains a set of managed
   -- objects describing the capabilities of the middlebox.
   -- All objects in this group have MAX-ACCESS read-only.


Quittek, Stiemerling                                           [Page 18]


Internet-Draft                 MIDCOM MIB                   October 2003


   --

   midcomCapabilities        OBJECT IDENTIFIER ::= { midcomObjects 1 }

   midcomCapabFirewall OBJECT-TYPE
       SYNTAX      TruthValue
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "When retrieved, this object returns true(1) if the managed
            node acts as firewall.  Otherwise, it returns false(2)."
       ::= { midcomCapabilities 1 }

   midcomCapabNat OBJECT-TYPE
       SYNTAX      TruthValue
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "When retrieved, this object returns true(1) if the managed
            node acts as network address tranlator.  Otherwise, it
            returns false(2)."
       ::= { midcomCapabilities 2 }

   midcomCapabPortTranslation OBJECT-TYPE
       SYNTAX      TruthValue
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "When retrieved, this object returns true(1) if the managed
            node acts as network address translator and supports port
            transaltion.  Otherwise, it returns false(2)."
       ::= { midcomCapabilities 3 }

   midcomCapabProtocolTranslation OBJECT-TYPE
       SYNTAX      TruthValue
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "When retrieved, this object returns true(1) if the managed
            node acts as network address translator and supports protocol
            transaltion.  Otherwise, it returns false(2)."
       ::= { midcomCapabilities 4 }

   midcomCapabTwiceNat OBJECT-TYPE
       SYNTAX      TruthValue
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "When retrieved, this object returns true(1) if the managed
            node acts as twice network address translator.  Otherwise,


Quittek, Stiemerling                                           [Page 19]


Internet-Draft                 MIDCOM MIB                   October 2003


            it returns false(2)."
       ::= { midcomCapabilities 5 }

   midcomCapabInsideIpVersions OBJECT-TYPE
       SYNTAX      INTEGER {
                       ipv4(1),
                       ipv6(2),
                       both(3)
                   }
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "When retrieved, this object returns ipv4(1) if the managed
            node supports IPv4 only at the inside.  It returns ipv6(2)
            if it supports IPv6 only at the inside.  Otherwise, if it
            supports voth IP version, it returns both(3)."
       ::= { midcomCapabilities 6 }

   midcomCapabOutsideIpVersions OBJECT-TYPE
       SYNTAX      INTEGER {
                       ipv4(1),
                       ipv6(2),
                       both(3)
                   }
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "When retrieved, this object returns ipv4(1) if the managed
            node supports IPv4 only at the outside.  It returns ipv6(2)
            if it supports IPv6 only at the outside.  Otherwise, if it
            supports voth IP version, it returns both(3)."
       ::= { midcomCapabilities 7 }

   midcomCapabInsideWildcards OBJECT-TYPE
       SYNTAX      TruthValue
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "When retrieved, this object returns true(1) if the managed
            node supports IP address wildcarding at the inde.  Otherwise,
           it returns false(2)."
       ::= { midcomCapabilities 8 }

   midcomCapabOutsideWildcards OBJECT-TYPE
       SYNTAX      TruthValue
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "When retrieved, this object returns true(1) if the managed
            node supports IP address wildcarding at the outde.  Otherwise,


Quittek, Stiemerling                                           [Page 20]


Internet-Draft                 MIDCOM MIB                   October 2003


           it returns false(2)."
       ::= { midcomCapabilities 9 }

   midcomCapabPortWildcards OBJECT-TYPE
       SYNTAX      TruthValue
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "When retrieved, this object returns true(1) if the managed
            node supports port wildcarding.  Otherwise, it returns
            false(2)."
       ::= { midcomCapabilities 10 }

   midcomCapabPersistentRules OBJECT-TYPE
       SYNTAX      TruthValue
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "When retrieved, this object returns true(1) if the managed
            node can store policy rules persistently.  Otherwise, it
            returns false(2)."
       ::= { midcomCapabilities 11 }

   midcomCapabMaxLifetime OBJECT-TYPE
       SYNTAX      TimeInterval
       UNITS       "centi-seconds"
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "When retrieved, this object returns the maximum lifetime
            in centi-seconds, that this middlebox allows policy rules
            to have."
       ::= { midcomCapabilities 12 }

   --
   -- Session group
   --
   -- The midcomSessionTable models MIDCOM sessions.
   -- MIDCOM agents ( = SNMP managers ) that want to
   -- read, create or modify entries in the midcomRuleTable
   -- or midcomGroupTable need to have an entry in this table.
   --
   -- The table contains objects identify a destination for
   -- notifications to be sent to the MIDCOM agent.
   -- Also it serves for creating new rows in the
   -- midcomRuleTable.
   --

   midcomSession        OBJECT IDENTIFIER ::= { midcomObjects 2 }



Quittek, Stiemerling                                           [Page 21]


Internet-Draft                 MIDCOM MIB                   October 2003


   midcomSessionIndexNext OBJECT-TYPE
       SYNTAX      Unsigned32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "When retrieved, this object returns an unused session
            index for the USM user that issued the read-request.
            The returned value can be used for creating a new entry
            in the midcomSessionTable.

            A value retuned when reading this object is not returned
            again on subsequent read-requests as long as possible.
            This ensures that two SNMP managers authenticated as the
            same USM user can independently create sessions without
            facing race conditions."
       ::= { midcomSession 1 }

   midcomSessionTable OBJECT-TYPE
       SYNTAX      SEQUENCE OF MidcomSessionEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "This table lists open MIDCOM sessions.

            The midcomSessionTable models MIDCOM sessions.
            MIDCOM agents ( = SNMP managers ) that want to
            read, create or modify entries in the midcomRuleTable
            or midcomGroupTable need to have an entry in this
            table.

            The table contains objects identify a destination for
            notifications to be sent to the MIDCOM agent.

            Also, it serves for creating new rows in the
            midcomRuleTable.

            The midcomSessionTable is indexed by its owner
            identified as USM user, and by a session index
            that allows distinguishing multiple sessions of
            the same USM users."
       ::= { midcomSession 2 }

   midcomSessionEntry OBJECT-TYPE
       SYNTAX      MidcomSessionEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "An entry describing a particular MIDCOM session."
       INDEX { midcomSessionOwner, midcomSessionIndex }
       ::= { midcomSessionTable 1 }


Quittek, Stiemerling                                           [Page 22]


Internet-Draft                 MIDCOM MIB                   October 2003


   MidcomSessionEntry ::= SEQUENCE {
       midcomSessionOwner               SnmpAdminString,
       midcomSessionIndex               Unsigned32,
       midcomSessionRuleGroupIndex      Unsigned32,
       midcomSessionRuleStorageTime     TimeInterval,
       midcomSessionRuleIndexNext       OBJECT IDENTIFIER,
       midcomSessionCreateRule          OBJECT IDENTIFIER,
       midcomSessionStorageType         StorageType,
       midcomSessionRowStatus           RowStatus
   }

   midcomSessionOwner OBJECT-TYPE
       SYNTAX      SnmpAdminString (SIZE (0..32))
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "The manager ( = MIDCOM agent ) who owns this row
            in the midcomSessionTable.

            Every policy rule created from a particular
            entry in the midcomSessionTable (i.e. entries
            in the midcomRuleTable) will be owned by the same
            midcomSessionOwner used to index the entry in the
            midcomSessionTable."
       ::= { midcomSessionEntry 1 }

   midcomSessionIndex OBJECT-TYPE
       SYNTAX      Unsigned32
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "This object allows distinguishing multiple concurrent
            sessions of the same USM user.  Its value needs to be
            unique per USM user."
       ::= { midcomSessionEntry 2 }

   midcomSessionRuleGroupIndex OBJECT-TYPE
       SYNTAX      Unsigned32
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "This object determines the index of the MIDCOM policy
            rule group of which policy rules becomes a member when
            they are created by writing to midcomSessionCreateRule.

            The value 0 is not a valid group index.  When this object
            has a value of 0, then a new group is created for each
            new policy rule generated by writing to
            midcomSessionCreateRule."
       DEFVAL { 0 }


Quittek, Stiemerling                                           [Page 23]


Internet-Draft                 MIDCOM MIB                   October 2003


       ::= { midcomSessionEntry 3 }

   midcomSessionRuleStorageTime OBJECT-TYPE
       SYNTAX      TimeInterval
       UNITS       "centi-seconds"
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "This object indicates the default maximum amount of time
            information on a policy rule is kept as entry in the
            mibRuleTable after the entry reaches an error state or
            after the policy rule is terminated.  The value of this
            object is used to initialize the midcomRuleStorageTime
            when a new entry in the midcomRuleTable is created.
            Changing the value of an midcomSessionRuleStorageTime
            instance does not affect any entry of the midcomRuleTable
            created previously."
       DEFVAL { 60000 }
       ::= { midcomSessionEntry 4 }

   midcomSessionRuleIndexNext OBJECT-TYPE
       SYNTAX      OBJECT IDENTIFIER
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "When retrieved, this object returns an object identifier
            pointing to a not yet existing row in the midcomRuleTable.

            The first index of the object identifier is the value of
            the midcomSessionOwner object of the actual entry in the
            midcomSessionTable.

            The second index is the value of the
            midcomSessionGroupIndex object of the actual entry in the
            midcomSessionTable, if this value is not 0.  If the value
            is zero, then the second index is the midcomGroupIndex of
            a not yet existing entry in the midcomGroupTable.

            The third index is a so far unused policy rule index for
            members of the group identified by the second index.

            The returned value can be used for creating a new entry
            in the midcomRuleTable by writing it to
            midcomSessionCreateRule."
       ::= { midcomSessionEntry 5 }

   midcomSessionCreateRule OBJECT-TYPE
       SYNTAX      OBJECT IDENTIFIER
       MAX-ACCESS  read-write
       STATUS      current


Quittek, Stiemerling                                           [Page 24]


Internet-Draft                 MIDCOM MIB                   October 2003


       DESCRIPTION
           "Writing to this object potentially creates a new entry in
            the midcomRuleTable.  A value written to this object should
            be an object identifier pointing to a so far not existing
            entry in the midcomRuleTable.  Also it should use the
            value of the midcomSessionOwner iobject of the acual
            entry in the midcomSessionTable as first index.  If one
            of these constraints is not given, then the operation
            will result in an inconsistentValue error.

            Also, the value must use the midcomSessionOwner of
            the actual entry in the midcomSessionTable as first index.
            Valid values for writing to this object can be obtained
            by reading the midcomSessionRuleIndexNext object.

            If the value is valid, then the MIDCOM MIB implementation
            creates a new entry in the midcomRuleTable using the
            value."
       ::= { midcomSessionEntry 6 }

   midcomSessionStorageType OBJECT-TYPE
       SYNTAX      StorageType
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "to be done"
       DEFVAL { volatile }
       ::= { midcomSessionEntry 7 }

   midcomSessionRowStatus OBJECT-TYPE
       SYNTAX      RowStatus
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "Needed for creating sessions. Detailed description
            to be done."
       ::= { midcomSessionEntry 8 }

   --
   -- Policy rule group
   --
   -- The midcomRuleTable lists all current policy rules
   -- including policy reserve rules and policy enable rules.
   --

   midcomRuleTable OBJECT-TYPE
       SYNTAX      SEQUENCE OF MidcomRuleEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION


Quittek, Stiemerling                                           [Page 25]


Internet-Draft                 MIDCOM MIB                   October 2003


           "This table lists all current policy rules.

            It is indexed by the midcomSessionOwner, the
            midcomGroupIndex and the midcomRuleIndex.
            This implies that a rule is member of exactly
            one group and that group membership cannot
            be changed.

            Entries in this table are created implicitly
            by writing to the midcomSessionTable.  Entries
            are deleted by writing to midcomGroupLifetime
            or midcomRuleLifetime."
       ::= { midcomObjects 3 }

   midcomRuleEntry OBJECT-TYPE
       SYNTAX      MidcomRuleEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "An entry describing a particular MIDCOM policy rule.
            It must be unque in combination with the
            midcomSessionOwner, the midcomGroupIndex, and the
            midcomRuleIndex of this entry."
       INDEX { midcomSessionOwner, midcomGroupIndex, midcomRuleIndex }
       ::= { midcomRuleTable 1 }

   MidcomRuleEntry ::= SEQUENCE {
       midcomRuleIndex             Unsigned32,
       midcomRuleAdminStatus       INTEGER,
       midcomRuleOperStatus        INTEGER,
       midcomRuleStorageType       StorageType,
       midcomRuleStorageTime       TimeInterval,
       midcomRuleError             SnmpAdminString,
       midcomRuleNatService        INTEGER,
       midcomRuleInternalIpVersion InetAddressType,
       midcomRuleInternalIpAddr    InetAddress,
       midcomRuleInternalPort      InetPortNumber,
       midcomRuleInsideIpVersion   InetAddressType,
       midcomRuleInsideIpAddr      InetAddress,
       midcomRuleInsidePort        InetPortNumber,
       midcomRuleInsideInterface   InterfaceIndex,
       midcomRuleOutsideIpVersion  InetAddressType,
       midcomRuleOutsideIpAddr     InetAddress,
       midcomRuleOutsidePort       InetPortNumber,
       midcomRuleOutsideInterface  InterfaceIndex,
       midcomRuleExternalIpVersion InetAddressType,
       midcomRuleExternalIpAddr    InetAddress,
       midcomRuleExternalPort      InetPortNumber,
       midcomRuleTransportProtocol Unsigned32, -- defintion?
       midcomRulePortRange         Unsigned32,


Quittek, Stiemerling                                           [Page 26]


Internet-Draft                 MIDCOM MIB                   October 2003


       midcomRulePortParity        INTEGER,
       midcomRuleFlowDirection     INTEGER,
       midcomRuleLifetime          TimeInterval
   }

   midcomRuleIndex OBJECT-TYPE
       SYNTAX     Unsigned32
       MAX-ACCESS not-accessible
       STATUS     current
       DESCRIPTION
           "The value of this object must be unique in
            combination with the values of
            midcomSessionOwner and midcomGroupIndex.

            The value of this index is chosen by the MIDCOM
            MIB implementation when a new entry in this row
            is created."
       ::= { midcomRuleEntry 3 }

   midcomRuleAdminStatus OBJECT-TYPE
       SYNTAX      INTEGER {
                       reserved(1),
                       enabled(2)
                   }
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
           "The value of this object indicates the desired status of
            the policy rule. See the definition of midcomRuleOperStatus
            for a description of the values.

            When the midcomRuleAdminStatus object is set, then the
            MIDCOM MIB implementation will try to read the respective
            relvant objects of the entry and try to achieve the
            corresponding midcomRuleOperStatus.

            Depending on whether the midcomRuleAdminStatus is set to
            reserved(1) or enabled(2) several entries in MidcomRuleEntry
            must be set.

            In the reserved(1) case these entries must be set for
            a request:
                - midcomRuleNatService
                - midcomRuleInternalIpVersion
                - midcomRuleInternalIpAddr
                - midcomRuleInternalPort
                - midcomRuleInsideInterface
                - midcomRuleOutsideInterface
                - midcomRuleExternalIpVersion
                - midcomRuleTransportProtocol


Quittek, Stiemerling                                           [Page 27]


Internet-Draft                 MIDCOM MIB                   October 2003


                - midcomRulePortRange
                - midcomRulePortParity

            In the enabled(2) case these entries must be set for a
            request:
                - midcomRuleInternalIpVersion
                - midcomRuleInternalIpAddr
                - midcomRuleInternalPort
                - midcomRuleInsideInterface
                - midcomRuleOutsideInterface
                - midcomRuleExternalIpVersion
                - midcomRuleExternalIpAddr
                - midcomRuleExternalPort
                - midcomRuleTransportProtocol
                - midcomRulePortRange
                - midcomRulePortParity
                - midcomRuleFlowDirection

            When retrieved, the object returns the last set value. If
            no value has been set, it returns one of the two possible
            values."
       ::= { midcomRuleEntry 4 }

   midcomRuleOperStatus OBJECT-TYPE
       SYNTAX      INTEGER {
                       newEntry(1),
                       setting(2),
                       checkingRequest(3),
                       incorrectRequest(4),
                       processingRequest(5),
                       requestRejected(6),
                       reserved(7),
                       checkingTransitRequest(8),
                       processingTransitRequest(9),
                       enabled(10),
                       timedOut(11),
                       terminatedOnRequest(12),
                       terminated(13),
                       genericError(14)
                   }
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "The actual status of the policy rule.  The
            midcomRuleOperStatus object may have the following values:

            - newEntry(1) indicates that the entry in the
              midcomRuleTable was created, but not modified yet.
              Such an entry needs to be filled with values specifying
              a request first.


Quittek, Stiemerling                                           [Page 28]


Internet-Draft                 MIDCOM MIB                   October 2003


            - setting(2) indicates that the entry has been already
              modified after generating it, but no request was made
              yet.

            - checkingRequest(3) indicates that midcomRuleAdminStatus
              has recently been set and that the MIDCOM MIB
              implementation is currently checking the parameters of
              the request.

            - incorrectRequest(4) indicates that checking a request
              resulted in detecting an incorrect value in one of the
              objects containing request parameters.  The failure
              reason is indicated by the value of midcomRuleError.

            - processingRequest(5) indicates that
              midcomRuleAdminStatus has recently been set and that
              the MIDCOM MIB implementation is currently processing
              the request and trying to configure the middlebox
              accordingly.

            - requestRejected(6) indicates that a request to establish
              a policy rule specified by the entry was rejected.  The
              reason of rejection is indicated by the value of
              midcomRuleError.

            - reserved(7) indicates that the entry describes an
              established policy reserve rule.
              These values of MidcomRuleEntry can be retrieved
              for a reserved policy rule:
                  - midcomRuleNatService
                  - midcomRuleInternalIpVersion
                  - midcomRuleInternalIpAddr
                  - midcomRuleInternalPort
                  - midcomRuleInsideIpVersion
                  - midcomRuleInsideIpAddr
                  - midcomRuleInsidePort
                  - midcomRuleInsideInterface
                  - midcomRuleOutsideIpVersion
                  - midcomRuleOutsideIpAddr
                  - midcomRuleOutsidePort
                  - midcomRuleExternalIpVersion
                  - midcomRuleTransportProtocol
                  - midcomRulePortRange
                  - midcomRulePortParity
                  - midcomRuleLifetime

            - checkingTransitRequest(8) indicates that after a policy
              reserve rule was established, midcomRuleAdminStatus has
              recently been set to enabled(10) and that the MIDCOM MIB
              implementation is currently checking the parameters of


Quittek, Stiemerling                                           [Page 29]


Internet-Draft                 MIDCOM MIB                   October 2003


              the request.

            - processingTransitRequest(9) indicates that after a policy
              reserve rule was established, midcomRuleAdminStatus has
              recently been set to enabled(10) and that the MIDCOM MIB
              implementation is currently processing the request and
              trying to configure the middlebox accordingly.

            - enabled(10) indicates that the entry describes an
              established policy enable rule.
              These values of MidcomRuleEntry can be retrieved
              for an enabled policy rule
                  - midcomRuleInternalIpVersion
                  - midcomRuleInternalIpAddr
                  - midcomRuleInternalPort
                  - midcomRuleInsideIpVersion
                  - midcomRuleInsideIpAddr
                  - midcomRuleInsidePort
                  - midcomRuleInsideInterface
                  - midcomRuleOutsideIpVersion
                  - midcomRuleOutsideIpAddr
                  - midcomRuleOutsidePort
                  - midcomRuleOutsideInterface
                  - midcomRuleExternalIpVersion
                  - midcomRuleExternalIpAddr
                  - midcomRuleExternalPort
                  - midcomRuleTransportProtocol
                  - midcomRulePortRange
                  - midcomRulePortParity
                  - midcomRuleFlowDirection
                  - midcomRuleLifetime

            - timedOut(11) indicates that the lifetime of a previously
              established policy rule is expired and that the policy
              rule is terminated for this reason.

            - terminatedOnRequest(12) indicates that a previously
              established policy rule was terminated by an SNMP
              manager setting the midcomRuleLifetime to 0 or
              setting midcomGroupLifetime to 0.

            - terminated(13) indicates that a previously established
              policy rule was terminated by the MIDCOM MIB
              implementation for another reason than lifetime
              expiration or an explicit request from an SNMP
              manager.

            - genericError(14) indicates that the policy rule
              specified by the entry is not established due to
              an error condition not listed above.


Quittek, Stiemerling                                           [Page 30]


Internet-Draft                 MIDCOM MIB                   October 2003


            The states timedOut(11), terminatedOnRequest(12) and
            terminated(13) are referred to as termination states.

            The states incorrectRequest(4), requestRejected(6)
            and genericError(14) are referred to as error states.

            The checkingRequest(3), processingRequest(4),
            checkingTransitRequest(8) and checkingTransitRequest(9)
            states are transient states which will either lead to one
            of the error states or the reserved(7) state or the
            enabled(10) states."
       DEFVAL { newEntry }
       ::= { midcomRuleEntry 5 }

   midcomRuleStorageType OBJECT-TYPE
       SYNTAX      StorageType
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "This object defines whether this row and the policy
            rule controlled by this row are kept in volatile
            storage and lost upon reboot or if this row is
            backed up by non-volatile or permanent storage.

            Attempts to set this object to permanent will always
            fail with an inconsistentValue error.

            If midcomRuleStorageType has the value permanent(4),
            then all objects whose MAX-ACCESS value is read-write
            must be read-only."
       DEFVAL { volatile }
       ::= { midcomRuleEntry 6 }

   midcomRuleStorageTime OBJECT-TYPE
       SYNTAX      TimeInterval
       UNITS       "centi-seconds"
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
           "The value of this object specifies how long this row
            can exist in the midcomRuleTable after the
            midcomRuleOperState switched to a termination state or
            to an error state.  This object returns the remaining
            time that the row may exist before it is aged out.

            The object is initialized with the value of the
            associated midcomSessionStorageTime object.

            After expiration or termination of the context, the value
            of this object ticks backwards.  The entry in the


Quittek, Stiemerling                                           [Page 31]


Internet-Draft                 MIDCOM MIB                   October 2003


            midcomRuleTable is destroyed when the value reaches 0.

            The value of this object may be set in order to increase
            or reduce the remaining time that the row may exist.
            Setting the value to 0 will destroy this entry as soon as
            the midcomRuleOperState switched to a termination state
            or to an error state.

            Note that there is no guarantee that the row is stored as
            long as this object indicates.  At any time, the SNMP
            agent 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
            anymore available."
       ::= { 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(10) failed.  Implementations must reset the
               error message to a zero-length string when a new
               attempt to change the policy rule status to reserved(7)
               or enabled(10) is started."
          DEFVAL { ''H }
          ::= { midcomRuleEntry 8 }

   midcomRuleNatService OBJECT-TYPE
       SYNTAX      INTEGER {
                       traditionalNat(1),
                       twiceNat(2)
                   }
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
        "The requested NAT service of the middlebox. Some NATs may
         have dual characters, like providing traditional and
         twice NAT service at the same time for different NAT bindings.
         This parameter determines the behaviour for this NAT binding.
         A firewall only middlebox ignores this parameter.

        The midcomRuleService is only available for policy reserve
         rules, indicated by midcomRuleAdminStatus set to reserved(1)."
       ::= { midcomRuleEntry 9 }

   midcomRuleInternalIpVersion OBJECT-TYPE


Quittek, Stiemerling                                           [Page 32]


Internet-Draft                 MIDCOM MIB                   October 2003


       SYNTAX      InetAddressType
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
        "IP version at the inside of the middlebox."
       ::= { midcomRuleEntry 10 }

   midcomRuleInternalIpAddr OBJECT-TYPE
       SYNTAX      InetAddress
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
           "The internal IP address at the middlebox."
       ::= { midcomRuleEntry 11 }

   midcomRuleInternalPort OBJECT-TYPE
       SYNTAX      InetPortNumber
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
           "The internal port at the middlebox."
       ::= { midcomRuleEntry 12 }

   midcomRuleInsideIpVersion OBJECT-TYPE
       SYNTAX      InetAddressType
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "IP version at the inside of the middlebox.
            The midcomRuleInsideIpVersion is set by the SNMP agent
            to the IP address type, when the middlebox is twice-NAT
            and twice-NAT service is requested.
            The midcomRuleInsideIpVersion must be set to unknown(0) when
            the NAT does not assign an inside IP address. Firewalls
            always return unkown(0), since no inside IP address is assigned."
       ::= { midcomRuleEntry 13 }

   midcomRuleInsideIpAddr OBJECT-TYPE
       SYNTAX      InetAddress
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "The inside IP address at the middlebox.
            The midcomRuleInsideIpAddr is set by the SNMP agent
            to the IP address, when the middlebox is twice-NAT
            and twice-NAT service is requested."
       ::= { midcomRuleEntry 14 }

   midcomRuleInsidePort OBJECT-TYPE
       SYNTAX      InetPortNumber


Quittek, Stiemerling                                           [Page 33]


Internet-Draft                 MIDCOM MIB                   October 2003


       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "The inside port at the middlebox.
            The midcomRuleInsideIpPort is set by the SNMP agent
            to the IP port number, when the middlebox is twice-NAT
            and twice-NAT service is requested."
       ::= { midcomRuleEntry 15 }

   midcomRuleInsideInterface OBJECT-TYPE
       SYNTAX      InterfaceIndex
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
           "The interface at the inside of the middlebox."
       ::= { midcomRuleEntry 16 }

   midcomRuleOutsideIpVersion OBJECT-TYPE
       SYNTAX      InetAddressType
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "IP version at the outside of the middlebox.
            The midcomRuleOutsideIpVersion is set by the SNMP agent
            to the IP address type.
            Firewalls always return unkown(0), since no inside IP address
            is assigned."
       ::= { midcomRuleEntry 17 }

   midcomRuleOutsideIpAddr OBJECT-TYPE
       SYNTAX      InetAddress
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "The outside IP address at the middlebox.
            The midcomRuleOutsideIpAddr is set by the SNMP agent
            to the IP address."
       ::= { midcomRuleEntry 18 }

   midcomRuleOutsidePort OBJECT-TYPE
       SYNTAX      InetPortNumber
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "The outside port at the middlebox.
            The midcomRuleOutsideIpPort is set by the SNMP agent
            to the IP address type."
       ::= { midcomRuleEntry 19 }

   midcomRuleOutsideInterface OBJECT-TYPE


Quittek, Stiemerling                                           [Page 34]


Internet-Draft                 MIDCOM MIB                   October 2003


       SYNTAX      InterfaceIndex
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
           "The interface at the outside of the middlebox."
       ::= { midcomRuleEntry 20 }

   midcomRuleExternalIpVersion OBJECT-TYPE
       SYNTAX      InetAddressType
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
           "IP version at the external of the middlebox."
       ::= { midcomRuleEntry 21 }

   midcomRuleExternalIpAddr OBJECT-TYPE
       SYNTAX      InetAddress
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
           "The external IP address at the middlebox.

            The midcomExternalIpAddr is only available for policy
            enable rule requests, indicated by midcomRuleAdminStatus set
            to enabled(2)."
       ::= { midcomRuleEntry 22 }

   midcomRuleExternalPort OBJECT-TYPE
       SYNTAX      InetPortNumber
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
           "The external port at the middlebox.
            The midcomExternalPort is only available for policy
            enable rule requests, indicated by midcomRuleAdminStatus set
            to enabled(2)."
       ::= { midcomRuleEntry 23 }

   midcomRuleTransportProtocol OBJECT-TYPE
       SYNTAX      Unsigned32 (0..255)
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
           "The transport protocol."
       ::= { midcomRuleEntry 24 }

   midcomRulePortRange OBJECT-TYPE
       SYNTAX      Unsigned32 (1..65535)
       MAX-ACCESS  read-write
       STATUS      current


Quittek, Stiemerling                                           [Page 35]


Internet-Draft                 MIDCOM MIB                   October 2003


       DESCRIPTION
           "The port range parameter specifies a number of
            consecutive port numbers.  Its value is a positive integer.
            Together with the port number parameter this parameter defines
            a set of consecutive port numbers starting with the port number
            specified by the port number parameter as the lowest port
            number and having as many elements as specified by the port
            range parameter.  A value of one specifies just a single port
            number."
       ::= { midcomRuleEntry 25 }

   midcomRulePortParity OBJECT-TYPE
       SYNTAX      INTEGER {
                       same(1),           -- available for PER only
                       any(2),            -- available for PER and PRR
                       odd(3),            -- available for PRR only
                       even(4)            -- available for PRR only
                   }
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
           "The port parity parameter is differently used in the
            context of policy reserve rules (PRR, midcomRuleAdminStatus
            set to reserved(1)) and policy enable rules (PER,
            midcomRuleAdminStaus set to enabled(2)). In the context
            of a PRR, the value of the parameter may be 'odd',
            'even', or 'any'.  It specifies the parity of the first
            (lowest) reserved port number.

            In the context of a PER, the port parity parameter
            indicates to the middlebox, whether or not port numbers
            allocated at the middlebox should have the same parity
            as the corresponding internal or external port numbers,
            respectively.  In this context, the parameter has either
            the value 'same' or 'any'.  If it has the value 'same',
            then the parity of the port number of A0 must be the
            same as the parity of the port number of A2, and the
            parity of the port number of A1 must be the same as the
            parity of the port number of A3.  If the port parity
            parameter has the value 'any', then there are no constraints
            on the parity of any port number."
       ::= { midcomRuleEntry 26}

   midcomRuleFlowDirection OBJECT-TYPE
       SYNTAX      INTEGER {
                       inbound(1),
                       outbound(2),
                       bidirectional(3)
                   }
       MAX-ACCESS  read-write


Quittek, Stiemerling                                           [Page 36]


Internet-Draft                 MIDCOM MIB                   October 2003


       STATUS      current
       DESCRIPTION
           "This parameter specifies the direction of enabled communication,
            either 'inbound', 'outbound', or 'bi-directional'.

            The midcomRuleFlowDirection is only available for policy
            enable rule requests, indicated by midcomRuleAdminStatus set
            to enabled(2)."
       ::= { midcomRuleEntry 27 }

   midcomRuleLifetime OBJECT-TYPE
       SYNTAX      TimeInterval
       UNITS       "centi-seconds"
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
           "When retrieved, this object delivers the the reamining
            lifetime in centi-seconds of this policy rule.

            Successfully writing to this object modifies the
            lifetime of the policy rule.  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 is processed by the SNMP agent
            according to the processing of a Policy Rule Lifetime Change
            (RLC) request as specified in RFC XXXX.  Therefore,
            SNMP set requests to this object might be rejected or
            the value of the object after an accepted set operation
            may be different from the value that was contained in
            the SNMP set request."
       ::= { midcomRuleEntry 28 }


   --
   -- Policy rule group group
   --
   -- The midcomGroupTable lists all current policy rule groups.
   --

   midcomGroupTable OBJECT-TYPE
       SYNTAX      SEQUENCE OF MidcomGroupEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "This table lists all current policy rule groups.



Quittek, Stiemerling                                           [Page 37]


Internet-Draft                 MIDCOM MIB                   October 2003


            Entries in this table are created implicitely when
            entries in the midcomRuleTable are created.

            Like the midcomSessionTable and the midcomRuleTable,
            this table is indexed by an owner and an index that
            is unique per owner.

            The table serves for listing the existing groups and
            their remaining lifetimes and for changing lifetimes
            of groups and implicitly of all group members.
            Groups and all their member policy rules can be
            deleted by setting midcomGroupLifetime to 0."
       ::= { midcomObjects 4 }

   midcomGroupEntry OBJECT-TYPE
       SYNTAX      MidcomGroupEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "An entry describing a particular MIDCOM session."
       INDEX { midcomSessionOwner, midcomGroupIndex }
       ::= { midcomGroupTable 1 }

   MidcomGroupEntry ::= SEQUENCE {
       midcomGroupIndex      Unsigned32,
       midcomGroupLifetime   TimeInterval
   }

   midcomGroupIndex OBJECT-TYPE
       SYNTAX      Unsigned32 (1..4294967295)
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "The index of this group for the midcomSessionOwner.
            A group is identified by the combination of
            midcomSessionOwner and midcomGroupIndex.

            The value of this index must be unique per
            midcomSessionOwner."
       ::= { midcomGroupEntry 2 }

   midcomGroupLifetime OBJECT-TYPE
       SYNTAX      TimeInterval
       UNITS       "centi-seconds"
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
           "When retrieved, this object delivers the the maximum
            lifetime in centi-seconds of all member rules of this
            group, i.e.  of all rows in the midcomRuleTable that


Quittek, Stiemerling                                           [Page 38]


Internet-Draft                 MIDCOM MIB                   October 2003


            have the same values for midcomSessionOwner and
            midcomGroupIndex.

            Successfully writing to this object modifies the
            lifetime of all member policies.  Successfully
            writing a value of 0 deletes the group and all its
            member rules.

            Note that after a group is conceptually deleted,
            still the corresponding entry in the midcomGroupTable
            will exist as long as terminated member policy rules
            are stored as entries in the midcomRuleTable.

            Writing to this object is processed by the SNMP agent
            according to the processing of a Group Lifetime Change
            (GLC) request as specified in RFC XXXX.  Therefore,
            SNMP set requests to this object might be rejected or
            the value of the object after an accepted set operation
            may be different from the value that was contained in
            the SNMP set request."
       ::= { midcomGroupEntry 3 }

   --
   -- Notifications. The definition of midcomEvent makes notification
   -- registrations reversible (see STD 58, RFC 2578, Section 8.5).
   --

   midcomEvent OBJECT IDENTIFIER ::= { midcomNotifications 0 }

   midcomSessionTermination NOTIFICATION-TYPE
       STATUS      current
       DESCRIPTION
           "This notification can be generated for indicating
         that a session is terminated by the middlebox."
       ::= { midcomEvent 1 }

   midcomRuleEvent NOTIFICATION-TYPE
       OBJECTS     { midcomRuleLifetime }
       STATUS      current
       DESCRIPTION
           "This notification can be generated for indicating the
            change of a policy rule's lifetime."
       ::= { midcomEvent 2 }

   midcomGroupEvent NOTIFICATION-TYPE
       OBJECTS     { midcomGroupLifetime }
       STATUS      current
       DESCRIPTION
           "This notification can be generated for indicating the
         change of a policy rule group's lifetime."


Quittek, Stiemerling                                           [Page 39]


Internet-Draft                 MIDCOM MIB                   October 2003


       ::= { midcomEvent 3 }

   --
   -- Conformance information
   --

   midcomCompliances OBJECT IDENTIFIER ::= { midcomConformance 1 }
   midcomGroups      OBJECT IDENTIFIER ::= { midcomConformance 2 }

   --
   -- compliance statements
   --

   -- This is the MIDCOM compliance definition ...
   --

   midcomCompliance MODULE-COMPLIANCE
       STATUS      current
       DESCRIPTION
           "The compliance statement for SNMP entities that
            implement the MIDCOM MIB.

            Note that compliance with this compliance
            statement requires compliance with the
            ifCompliance3 MODULE-COMPLIANCE statement of the
            IF-MIB [RFC2863]."
       MODULE      -- this module
       MANDATORY-GROUPS {
               midcomCapabilitiesGroup,
               midcomSessionGroup,
               midcomRuleGroup,
               midcomNotificationsGroup
       }
       GROUP   midcomGroupGroup
       DESCRIPTION
          "A compliant implementation does not have to implement
           the midcomGroupGroup."
       OBJECT  midcomRuleInsideInterface
       MIN-ACCESS  not-accessible
       DESCRIPTION
           "A compliant implementation does not have to implement
            object midcomRuleInsideInterface."
       OBJECT  midcomRuleOutsideInterface
       MIN-ACCESS  not-accessible
       DESCRIPTION
           "A compliant implementation does not have to implement
            object midcomRuleOutsideInterface."
       ::= { midcomCompliances 1 }

   midcomCapabilitiesGroup OBJECT-GROUP


Quittek, Stiemerling                                           [Page 40]


Internet-Draft                 MIDCOM MIB                   October 2003


       OBJECTS {
           midcomCapabFirewall,
           midcomCapabNat,
           midcomCapabPortTranslation,
           midcomCapabProtocolTranslation,
           midcomCapabTwiceNat,
           midcomCapabInsideIpVersions,
           midcomCapabOutsideIpVersions,
           midcomCapabInsideWildcards,
           midcomCapabOutsideWildcards,
           midcomCapabPortWildcards,
           midcomCapabPersistentRules,
           midcomCapabMaxLifetime
       }
       STATUS      current
       DESCRIPTION
           "A collection of objects providing information about
            the capabilities of a middlebox."
       ::= { midcomGroups 1 }

   midcomSessionGroup OBJECT-GROUP
       OBJECTS {
           midcomSessionIndexNext,
           midcomSessionRuleGroupIndex,
           midcomSessionRuleStorageTime,
           midcomSessionRuleIndexNext,
           midcomSessionCreateRule,
           midcomSessionStorageType,
           midcomSessionRowStatus
       }
       STATUS      current
       DESCRIPTION
           "A collection of objects providing information about
            MIDCOM sessions."
       ::= { midcomGroups 2 }

   midcomRuleGroup OBJECT-GROUP
       OBJECTS {
            midcomRuleAdminStatus,
            midcomRuleOperStatus,
            midcomRuleStorageType,
            midcomRuleStorageTime,
            midcomRuleError,
            midcomRuleNatService,
            midcomRuleInternalIpVersion,
            midcomRuleInternalIpAddr,
            midcomRuleInternalPort,
            midcomRuleInsideIpVersion,
            midcomRuleInsideIpAddr,
            midcomRuleInsidePort,


Quittek, Stiemerling                                           [Page 41]


Internet-Draft                 MIDCOM MIB                   October 2003


            midcomRuleInsideInterface,
            midcomRuleOutsideIpVersion,
            midcomRuleOutsideIpAddr,
            midcomRuleOutsidePort,
            midcomRuleOutsideInterface,
            midcomRuleExternalIpVersion,
            midcomRuleExternalIpAddr,
            midcomRuleExternalPort,
            midcomRuleTransportProtocol,
            midcomRulePortRange,
            midcomRulePortParity,
            midcomRuleFlowDirection,
            midcomRuleLifetime
        }
        STATUS      current
        DESCRIPTION
            "A collection of objects providing information about
             policy rules."
        ::= { midcomGroups 3 }

   midcomGroupGroup OBJECT-GROUP
       OBJECTS {
           midcomGroupLifetime
       }
       STATUS      current
       DESCRIPTION
           "A collection of objects providing information about
            policy rule groups."
       ::= { midcomGroups 4 }

   midcomNotificationsGroup OBJECT-GROUP
        OBJECTS {
            midcomSessionTermination,
         midcomRuleEvent,
         midcomGroupEvent
        }
        STATUS    current
        DESCRIPTION
            "The notifications emitted by the midcomMIB."
        ::= { midcomGroups 5 }

   END




7.  Usage Examples

   This section presents some examples that explain how a manager can
   use the MIDCOM MIB defined in this memo.  The purpose of these


Quittek, Stiemerling                                           [Page 42]


Internet-Draft                 MIDCOM MIB                   October 2003


   examples is to explain the steps that are normally used to perform
   MIDCOM transactions.  For each MIDCOM transaction defined in the
   MIDCOM semantics in RFC XXXX, a sequence of SNMP operations is
   described, which realizes the transaction.

   We see three different ways, a MIDCOM agent can choose to operate on
   the MIDCOM MIB.  The first one is in line with the MIDCOM semantics.
   It models MIDCOM transactions as described in section 4.2 using SNMP
   notifications for signaling completion of processing a transaction
   from the MIDCOM MIB implementation to the MIDCOM agent.

   The second way uses notifications in configuration transactions only
   in 'unexpected' cases, when a request failes.  The third one does not
   use notifications at all in configuration transaction.  We describe
   the realization of MIDCOM transactions for the first way of operating
   on the MIDCOM MIB.  For the other two ways, just the differences to
   the first ways are summarized at the end of this section.

7.1.  Session Establishment (SE)

   This example explains the steps performed by an SNMP manager to
   establish a MIDCOM session.

   1. The MIDCOM agent first checks the middlebox capabilities by
      reading objects in the midcomCapabilities group.

   2. The MIDCOM agent reads the midcomSessionNextIndex object in order
      to receive an index for creating a session.

   3. The manager creates a row in the midcomSessionTable by issuing an
      SNMP set-request.  The midcomSessionRowStatus object is set to
      createAndWait(5).  The new row is indexed by the MIDCOM agent's
      USM user name and by the index read from the
      midcomSessionNextIndex object in step 2.

   4. If the MIDCOM agent wants to have policies stored in the
      midcomRuleTable for some time after they are terminated, then it
      sets the midcomSessionRuleStorageTime object to the desired value.
      Otherwise, the default value of zero will be applied to the
      storage time of entries in the midcomRuleTable as long as the
      MIDCOM agent does not change this object.

   5. If the agent wants to have all policy rules it creates to be
      member of the same policy rule group, then the MIDCOM agent should
      set the midcomSessionRuleGroupIndex to the group index that is to
      be used.






Quittek, Stiemerling                                           [Page 43]


Internet-Draft                 MIDCOM MIB                   October 2003


7.2.  Session Termination (ST)

   This example explains the steps performed by an SNMP manager to
   terminate a MIDCOM session.

   1. The manager sends an SNMP set-request to change the
      midcomSessionRowStatus object to destroy(6).  This will remove the
      row from the midcomSessionTable but not have an effect on entries
      in the midcomRuleTable created from this session.

7.3.  Asynchronous Session Termination (AST)

   At any time, the MIDCOM MIB implementation may terminate a session.
   Only two steps are required for performing this transaction.

   1. The MIDCOM MIB implementation sends a midcomSessionTermination
      notification to the SNMP manager owning the session.

   2. The MIDCOM MIB implementation removes the corresponding row of the
      midcomSessionTable.  This does not affect entries in other tables.

7.4.  Policy Reserve Rule (PRR)

   This example explains the steps performed by an SNMP manager to
   establish a policy reserve rule.

   1. If the new policy rule should become a member of an already
      existing policy rule group, then the SNMP manager sets the
      midcomSessionGroupIndex object to the index of that group.
      Otherwise, it sets this object to 0.

   2. The SNMP manager reads the midcomSessionRuleNextIndex for an open
      entry in the modcomSessionTable in order to receive an object
      identifier for creating a new entry in the midcomRuleTable.

   3. The SNMP manager sets the midcomSessionCreateRule object to the
      value read in step 2.  This creates a new row in the
      midcomRuleTable that is addressed by the object idenitfier written
      to the midcomSessionCreateRule object.

   4. The SNMP manager sets the following objects in the new row of the
      midcomRuleTable to specify all request parameters of the PRR
      transaction:
         - midcomRuleNatService
         - midcomRuleInternalIpVersion
         - midcomRuleInternalIpAddr
         - midcomRuleInternalPort
         - midcomRuleInsideInterface
         - midcomRuleOutsideInterface
         - midcomRuleExternalIpVersion


Quittek, Stiemerling                                           [Page 44]


Internet-Draft                 MIDCOM MIB                   October 2003


         - midcomRuleTransportProtocol
         - midcomRulePortRange
         - midcomRulePortParity
         - midcomRuleLifeime

   5. The SNMP manager sets the midcomRuleAdminStatus objects in the new
      row of the midcomRuleTable to reserved(1).

   6. The SNMP manager waits for a midcomRuleEvent notification
      concerning the new row in the midcomSessionTable.

   7. After receiving the midcomRuleEvent notification SNMP manager
      checks the lifetime value carried by the notification.  If it is
      greater than 0, the SNMP manager read all positive reply
      parameters of the PRR transaction:
         - midcomRuleInsideIpAddr
         - midcomRuleInsidePort
         - midcomRuleOutsideIpAddr
         - midcomRuleOutsidePort
         - midcomRuleLifetime

      If the lifetime equals 0, then SNMP manager reads the
      midcomRuleOperStatus and the midcomRuleError in order to analyze
      the failure reason.

7.5.  Policy Enable Rule (PER) after PRR

   This example explains the steps performed by an SNMP manager to
   establish a policy enable rule after a corresponding policy reserve
   rule was already established.

   1. The SNMP manager sets the following objects in the row of the
      established PRR in the midcomRuleTable to specify all request
      parameters of the PER transaction:
         - midcomRuleExternalIpAddr
         - midcomRuleExternalPort
         - midcomRulePortParity
         - midcomRuleFlowDirection

   2. The SNMP manager sets the midcomRuleAdminStatus objects in the row
      of the established PRR in the midcomRuleTable to enabled(1).

   3. The SNMP manager waits for a midcomRuleEvent notification
      concerning the new row in the midcomSessionTable.

   4. After receiving the midcomRuleEvent notification SNMP manager
      checks the lifetime value carried by the notification.  If it is
      greater than 0, the SNMP manager read all positive reply
      parameters of the PER transaction:
         - midcomRuleInsideIpAddr


Quittek, Stiemerling                                           [Page 45]


Internet-Draft                 MIDCOM MIB                   October 2003


         - midcomRuleInsidePort
         - midcomRuleOutsideIpAddr
         - midcomRuleOutsidePort
         - midcomRuleLifetime

      If the lifetime equals 0, then SNMP manager reads the
      midcomRuleOperStatus and the midcomRuleError in order to analyze
      the failure reason.

7.6.  Policy Enable Rule (PER) without previous PRR

   This example explains the steps performed by an SNMP manager to
   establish a policy enable rule for which no PRR transaction has been
   performed before.

   1. Identical to step 1 for PRR.

   2. Identical to step 2 for PRR.

   3. Identical to step 3 for PRR.

   4. The SNMP manager sets the following objects in the new row of the
      midcomRuleTable to specify all request parameters of the PER
      transaction:
         - midcomRuleInternalIpVersion
         - midcomRuleInternalIpAddr
         - midcomRuleInternalPort
         - midcomRuleInsideInterface
         - midcomRuleOutsideInterface
         - midcomRuleExternalIpVersion
         - midcomRuleExternalIpAddr
         - midcomRuleExternalPort
         - midcomRuleTransportProtocol
         - midcomRulePortRange
         - midcomRulePortParity
         - midcomRuleFlowDirection
         - midcomRuleLifetime

   5. The SNMP manager sets the midcomRuleAdminStatus objects in the new
      row of the midcomRuleTable to enabled(1).

   6. Identical to step 6 for PRR.

   7. After receiving the midcomRuleEvent notification SNMP manager
      checks the lifetime value carried by the notification.  If it is
      greater than 0, the SNMP manager read all positive reply
      parameters of the PRR transaction:
         - midcomRuleInsideIpAddr
         - midcomRuleInsidePort
         - midcomRuleOutsideIpAddr


Quittek, Stiemerling                                           [Page 46]


Internet-Draft                 MIDCOM MIB                   October 2003


         - midcomRuleOutsidePort
         - midcomRuleFlowDirection
         - midcomRuleLifetime

      If the lifetime equals 0, then SNMP manager reads the
      midcomRuleOperStatus and the midcomRuleError in order to analyze
      the failure reason.

7.7.  Policy Rule Lifetime Change (RLC)

   This example explains the steps performed by an SNMP manager to
   change the lifetime of a policy rule.  Changing the lifetime to 0
   implies terminating the policy rule.

   1. The SNMP manager issues a set-request for writing the desired
      lifetime to the midcomRuleLifetime object in the corresponding row
      of the midcomRuleTable.

   2. The SNMP manager waits for a midcomRuleEvent notification
      concerning the corresponding row in the midcomRuleTable.

   3. After receiving the midcomRuleEvent notification SNMP manager
      checks the lifetime value carried by the notification.

7.8.  Policy Rule List (PRL)

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

7.9.  Policy Rule Status (PRS)

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

7.10.  Asynchronous Policy Rule Event (ARE)

   At any time, the MIDCOM MIB implementation may terminate a policy
   rule.  in this case two steps are required for performing this
   transaction:

   1. The MIDCOM MIB implementation sends a midcomRuleEvent notification
      containing a lifetime value of 0 to the SNMP manager owning the
      session.

   2. If the midcomRuleStorageTime object in the corresponding row of
      the midcomRuleTable has a value of 0 then the MIDCOM MIB


Quittek, Stiemerling                                           [Page 47]


Internet-Draft                 MIDCOM MIB                   October 2003


      implementation removes the row from the table.  Otherwise, it
      changes in this row the midcomRuleLifetime object to 0 and the
      midcomRuleOperStatus object to terminated(13).

   The procedure is the same if the lifetime of a policy rule expires.
   The only difference is that the midcomRuleOperStatus object is set to
   timedOut(11) instead of terminated(13).

7.11.  Group Lifetime Change (GLC)

   This example explains the steps performed by an SNMP manager to
   change the lifetime of a policy rule group.  Changing the lifetime to
   0 implies terminating all member policies of the group.

   1. The SNMP manager issues a set-request for writing the desired
      lifetime to the midcomGroupLifetime object in the corresponding
      row of the midcomGroupTable.

   2. The SNMP manager waits for a midcomGroupEvent notification
      concerning the corresponding row in the midcomGroupTable.

   3. After receiving the midcomRuleEvent notification SNMP manager
      checks the lifetime value carried by the notification.

7.12.  Group List (GL)

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

7.13.  Group Status (GS)

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

7.14.  Using Notifications For Negative Replies Only

   To be done.

7.15.  Not Using Notifications For Replies

   To be done.






Quittek, Stiemerling                                           [Page 48]


Internet-Draft                 MIDCOM MIB                   October 2003


8.  Security Considerations

   Still to be completed. Very important for this module!  More text
   here ....


   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.

   It is REQUIRED that implementers consider the security features as
   provided by the SNMPv3 framework (see [RFC3410], section 8),
   including full support for the SNMPv3 cryptographic mechanisms (for
   authentication and privacy).

   For implementations of the MIDCOM MIB it is REQUIRED to deploy SNMPv3
   and to enable cryptographic security.  It is then a customer/operator
   responsibility to ensure that the SNMP entity giving access to an
   instance of this MIB module 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.


9.  Open Issues

      - notification identifiers, transaction identifiers
      - effect on other MIB modules missing
      - security considerations not complete
      - discuss atomicity of PRR and PER transactions
      - grop lifetime: ref to semantics not appropriate
      - rule lifetime: ref to semantics not appropriate
      - centi-seconds or seconds?
      - session index requred?
      - DEFVAL for A0, A1, A2, A3
      - collision of midcomRulePortParity usage
      - redundant inside/outside IpVersions
      - missing description of midcomsessionIndexNext
      - means for configuring which notifications to receive
      - examples for using less notifications
      - a set of issues raised by David Harrington


10.  Normative References


[RFC3303]   Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A. and A.
            Rayhan, "Middlebox communication architecture and
            framework", RFC 3303, August 2002.


Quittek, Stiemerling                                           [Page 49]


Internet-Draft                 MIDCOM MIB                   October 2003


[RFC3304]   Swale, R.P., Mart, P.A., Sijben, P., Brimm, S. and M. Shore,
            "Middlebox Communications (midcom) Protocol Requirements",
            RFC 3304, August 2002.

[RFCXXXX]   Stiemerling, M., Quittek, J. and T. Tailor, "Middlebox
            Communications (midcom) protocol semantics", RFC XXXX,
            YYYYmonth 2003, <draft-ietf-midcom-semantics-03.txt>.

[RFC2578]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
            Rose, M. and S. Waldbusser, "Structure of Management
            Information Version 2 (SMIv2)", STD 58, RFC 2578, April
            1999.

[RFC2579]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
            Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2",
            STD 58, RFC 2579, April 1999.

[RFC2580]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
            Rose, M. and S. Waldbusser, "Conformance Statements for
            SMIv2", STD 58, RFC 2580, April 1999.

[RFC3411]   Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture
            for Describing Simple Network Management Protocol (SNMP)
            Management Frameworks", STD 62, RFC 3411, December 2002.

[RFC2863]   McCloghrie, K. and F. Kastenholz, "The Interfaces Group
            MIB", RFC 2863, June 2000.

[RFC2574]   Blumenthal, U., and B. Wijnen, "User-based Security Model
            (USM) for version 3 of the Simple Network Management
            Protocol (SNMPv3)", RFC 2574, April 1999.


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

[NAT-TERM]  Srisuresh,P., and Holdrege, M., "IP Network Translator (NAT)
            Terminology and Considerations", RFC 2663, August 1999.

[RFC2246]   Dierks, T., Allen, C., "The TLS Protocol Version 1.0", RFC
            2246, January 1999.

[RFC2402]   Kent, S., and Atkinson, R., "IP Authentication Header", RFC
            2402, November 1998.

[RFC2406]   Kent, S., and Atkinson, R., "IP Encapsulating Security
            Payload (ESP)", RFC 2406, November 1998.


Quittek, Stiemerling                                           [Page 50]


Internet-Draft                 MIDCOM MIB                   October 2003


12.  Authors' Addresses

     Juergen Quittek
     NEC Europe Ltd.
     Network Laboratories
     Kurfuersten-Anlage 34
     69115 Heidelberg
     Germany

     Phone: +49 6221 90511-15
     EMail: quittek@ccrle.nec.de


     Martin Stiemerling
     NEC Europe Ltd.
     Network Laboratories
     Kurfuersten-Anlage 34
     69115 Heidelberg
     Germany

     Phone: +49 6221 90511-13
     Email: stiemerling@ccrle.nec.de



13.  Full Copyright Statement

   Copyright (C) The Internet Society (2003). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the  purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION


Quittek, Stiemerling                                           [Page 51]


Internet-Draft                 MIDCOM MIB                   October 2003


   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


















































Quittek, Stiemerling                                           [Page 52]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/