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