[RFCs/IDs] [Plain Text] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]
Versions: (draft-barnes-midcom-mib) 00 01 02
03 04 05 06 07 08 09 10 11 RFC 5190
Internet Draft J. Quittek
Document: draft-ietf-midcom-mib-11.txt M. Stiemerling
Intended Status: Standards Track NEC
Expires: June 6, 2008 P. Srisuresh
Consultant
December 6, 2007
Definitions of Managed Objects for Middlebox Communication
<draft-ietf-midcom-mib-11.txt>
Status of this Memo
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 becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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.
This Internet-Draft will expire on May 15, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes a set of managed objects that allow
configuring middleboxes, such as firewalls and network address
translators, in order to enable communication across these devices.
The definitions of managed objects in this documents follow closely
the MIDCOM semantics defined in [I-D.ietf-midcom-rfc3989-bis].
Quittek, Stiemerling, Srisuresh [Page 1]
Internet-Draft MIDCOM MIB December 2007
Table of Contents
1 Introduction ................................................. 3
2 The Internet-Standard Management Framework ................... 3
3 Overview ..................................................... 3
3.1 Terminology ................................................ 4
4 Realizing the MIDCOM Protocol with SNMP ...................... 4
4.1 MIDCOM Sessions ............................................ 5
4.1.1 Authentication and Authorization ......................... 5
4.2 MIDCOM Transactions ........................................ 6
4.2.1 Asynchronous Transactions ................................ 6
4.2.2 Configuration Transactions ............................... 7
4.2.3 Monitoring Transactions .................................. 10
4.2.4 Atomicity of MIDCOM Transactions ......................... 11
4.2.4.1 Asynchronous MIDCOM Transactions ....................... 11
4.2.4.2 Session Establishment and Termination Transactions ..... 11
4.2.4.3 Monitoring Transactions ................................ 12
4.2.4.4 Lifetime Change Transactions ........................... 12
4.2.4.5 Transactions Establishing New Policy Rules ............. 12
4.2.5 Access Control ........................................... 13
4.3 Access Control Policies .................................... 13
5 Structure of the MIB module .................................. 15
5.1 Transaction Objects ........................................ 16
5.1.1 midcomRuleTable .......................................... 16
5.1.2 midcomGroupTable ......................................... 19
5.2 Configuration Objects ...................................... 19
5.2.1 Capabilities ............................................. 20
5.2.2 midcomConfigFirewallTable ................................ 20
5.3 Monitoring Objects ......................................... 21
5.3.1 midcomResourceTable ...................................... 21
5.3.2 midcomStatistics ......................................... 23
5.4 Notifications .............................................. 24
6 Recommendations for Configuration and Operation .............. 26
6.1 Security Model Configuration ............................... 26
6.2 VACM Configuration ......................................... 26
6.3 Notification Configuration ................................. 27
6.4 Simultaneous Access ........................................ 27
6.5 Avoiding Idempotency Problems .............................. 28
6.6 Interface Indexing Problems ................................ 28
6.7 Applicability Restrictions ................................. 29
7 Usage Examples for MIDCOM Transactions ....................... 30
7.1 Session Establishment (SE) ................................. 30
7.2 Session Termination (ST) ................................... 30
7.3 Policy Reserve Rule (PRR) .................................. 31
7.4 Policy Enable Rule (PER) after PRR ......................... 32
7.5 Policy Enable Rule (PER) without previous PRR .............. 33
7.6 Policy Rule Lifetime Change (RLC) .......................... 34
7.7 Policy Rule List (PRL) ..................................... 34
7.8 Policy Rule Status (PRS) ................................... 34
7.9 Asynchronous Policy Rule Event (ARE) ....................... 34
Quittek, Stiemerling, Srisuresh [Page 2]
Internet-Draft MIDCOM MIB December 2007
7.10 Group Lifetime Change (GLC) ............................... 35
7.11 Group List (GL) ........................................... 35
7.12 Group Status (GS) ......................................... 35
8 Usage Examples for Monitoring Objects ........................ 36
8.1 Monitoring NAT Resources ................................... 36
8.2 Monitoring Firewall Resources .............................. 36
9 Definitions .................................................. 38
10 Security Considerations ..................................... 83
10.1 General Security Issues ................................... 83
10.2 Unauthorized Middlebox Configuration ...................... 84
10.3 Unauthorized Access to Middlebox Configuration ............ 85
10.4 Unauthorized Access to MIDCOM Service Configuration ....... 85
11 Acknowledgements ............................................ 85
12 IANA Considerations ......................................... 86
13 Normative References ........................................ 86
14 Informative References ...................................... 87
15 Authors' Addresses .......................................... 88
Quittek, Stiemerling, Srisuresh [Page 3]
Internet-Draft MIDCOM MIB December 2007
1. Introduction
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes a set of managed objects that allow
controlling middleboxes.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. The Internet-Standard Management Framework
For a detailed overview of the documents that describe the current
Internet-Standard Management Framework, please refer to section 7 of
RFC 3410 [RFC3410].
Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. MIB objects are generally
accessed through the Simple Network Management Protocol (SNMP).
Objects in the MIB are defined using the mechanisms defined in the
Structure of Management Information (SMI). This memo specifies a MIB
module that is compliant to the SMIv2, which is described in STD 58,
RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
[RFC2580].
3. Overview
The managed objects defined in this document serve for controlling
firewalls and Network Address Translators (NATs). As defined in
[RFC3234], firewalls and NATs belong to the group of middleboxes. A
middlebox is a device on the datagram path between source and
destination, which performs other functions than just IP routing. As
outlined in [RFC3303], firewalls and NATs are potential obstacles to
packet streams, for example if dynamically negotiated UDP or TCP port
numbers are used, as in many peer-to-peer communication applications.
As one possible solution for this problem, the IETF MIDCOM working
group defined a framework [RFC3303], requirements [RFC3304] and
protocol semantics [I-D.ietf-midcom-rfc3989-bis] 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 a MIDCOM agent and a middlebox.
The managed objects defined in this document can be used for
dynamically configuring middleboxes on the datagram path to permit
Quittek, Stiemerling, Srisuresh [Page 4]
Internet-Draft MIDCOM MIB December 2007
datagrams traversing the middleboxes. This way, applications can,
for example, request pinholes at firewalls and address bindings at
NATs.
Besides managed objects for controlling the middlebox operation, this
document also defines managed objects that provide information on
middlebox resource usage (such as firewall pinholes, NAT bindings,
NAT sessions, etc.) affected by requests.
Since firewalls and NATs are critical devices concerning network
security, security issues of middlebox communication need to be
considered very carefully.
3.1. Terminology
The terminology used in this document is fully aligned with the
terminology defined in [I-D.ietf-midcom-rfc3989-bis] 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, also called MIDCOM
server. In order to avoid confusion in this document specifying a
MIB module, we replace the term 'MIDCOM agent' by 'MIDCOM client'.
Whenever the term 'agent' is used in this document, it refers to the
SNMP agent. Figure 1 sketches the entities of MIDCOM in relationship
to SNMP manager and SNMP agent.
+---------+ MIDCOM +-----------+
| MIDCOM |<~ ~ ~ ~ ~ ~ ~ ~>| MIDCOM |
| Client | Transaction | middlebox |
| | | (server) |
+---------+ +-----------+
^ ^
| |
v v
+---------+ +-----------+
| SNMP | SNMP | SNMP |
| Manager |<===============>| Agent |
+---------+ Protocol +-----------+
Figure 1: Mapping of MIDCOM to SNMP
4. Realizing the MIDCOM Protocol with SNMP
In order to realize middlebox communication as described in [I-
D.ietf-midcom-rfc3989-bis], several aspects and properties of the
Quittek, Stiemerling, Srisuresh [Page 5]
Internet-Draft MIDCOM MIB December 2007
MIDCOM protocol need to be mapped to SNMP capabilities and expressed
in terms of the Structure of Management Information version 2
(SMIv2).
Basic concepts to be mapped are MIDCOM sessions and MIDCOM
transactions. For both, access control policies need to be
supported.
4.1. MIDCOM Sessions
SNMP has no direct support for sessions. Therefore, they need to be
modeled. A MIDCOM session is stateful and has a context that is
valid for several transactions. For SNMP, a context is valid for a
single transaction only, for example covering just a single
request/reply pair of messages.
Properties of sessions that are utilized by the MIDCOM semantics and
not available in SNMP need to be modeled. Particularly, the
middlebox needs to be able to authenticate MIDCOM clients, authorize
access to policy rules, and send notification messages concerning
policy rules to MIDCOM clients participating in a session. In the
MIDCOM MIB module, authentication and access control are performed on
a per-message base using an SNMPv3 security model, such as the User-
based Security Model (USM) [RFC3414], for authentication, and the
View-based Access control Model (VACM) [RFC3415] for access control.
Sending notifications to MIDCOM clients is controlled by access
control models such as VACM and a mostly static configuration of
objects in the SNMP-TARGET-MIB [RFC3413] and the SNMP-NOTIFICATION-
MIB [RFC3413].
This session model is static except that the MIDCOM client can switch
on and off the generation of SNMP notifications that the middlebox
sends. Recommended configurations of VACM and the SNMP-TARGET-MIB
and the SNMP-NOTIFICATION-MIB that can serve for modeling a session
are described in detail in section 6.
4.1.1. Authentication and Authorization
MIDCOM sessions are required for providing authentication,
authorization and encryption for messages exchanged between a MIDCOM
client and a middlebox. SNMPv3 provides these features on a per-
message basis instead of a per-session basis applying a security
model and an access control model, such as USM and VACM. Per-message
security mechanisms can be considered as overhead compared to per-
session security mechanisms, but it certainly satisfies the security
requirements of middlebox communication.
For each authenticated MIDCOM client, access to the MIDCOM-MIB,
particularly to policy rules, should be configured as part of the
VACM configuration of the SNMP agent.
Quittek, Stiemerling, Srisuresh [Page 6]
Internet-Draft MIDCOM MIB December 2007
4.2. MIDCOM Transactions
[I-D.ietf-midcom-rfc3989-bis] defines the MIDCOM protocol semantics
in terms of transactions and transaction parameters. Transactions
are grouped into request-reply transactions and asynchronous
transactions.
SNMP offers simple transactions that in general cannot be mapped one-
to-one to MIDCOM transactions. This section describes how the MIDCOM
MIB module implements MIDCOM transactions using SNMP transactions.
The concerned MIDCOM transactions are asynchronous transactions and
request-reply transactions. Within the set of request-reply
transactions we distinguish configuration transactions and monitoring
transactions, because they are implemented in slightly different ways
by using SNMP transactions.
The SNMP terminology as defined in [RFC3411] does not use the concept
of transactions, but of SNMP operations. For the considerations in
this section we use the terms SNMP get transaction and SNMP set
transaction. An SNMP get transaction consists of an SNMP Read Class
operation and an SNMP Response Class operation. An SNMP set
transaction consists of an SNMP Write Class operation and an SNMP
Response Class operation.
4.2.1. Asynchronous Transactions
Asynchronous transactions can easily be modeled by SNMP Notification
Class operations. An asynchronous transaction contains a
notification message with one to three parameters. The message can
be realized as an SNMP Notification Class operation with the
parameters implemented as managed objects contained in the
notification.
Quittek, Stiemerling, Srisuresh [Page 7]
Internet-Draft MIDCOM MIB December 2007
+--------------+ notification +------------+
| MIDCOM client|<--------------| middlebox |
+--------------+ message +------------+
MIDCOM asynchronous transaction
+--------------+ SNMP +------------+
| SNMP manager |<--------------| SNMP agent |
+--------------+ notification +------------+
Implementation of MIDCOM asynchronous transaction
Figure 2: MIDCOM asynchronous transaction
mapped to SNMP Notification Class operation
One of the parameters is the transaction identifier that should be
unique per middlebox. It does not have to be unique for all
notifications sent by the particular SNMP agent, but for all sent
notifications that are defined by the MIDCOM MIB module.
Note, SNMP notifications are usually sent as unreliable UDP packets
and may be dropped before they reach their destination. If a MIDCOM
client is expecting an asynchronous notification on a specific
transaction, it would be the job of the MIDCOM client to poll the
middlebox periodically and monitor the transaction in case
notifications are lost along the way.
4.2.2. Configuration Transactions
All request-reply transactions contain a request message, a reply
message and potentially also a set of notifications. In general they
cannot be modeled by just having a single SNMP message per MIDCOM
message, because some of the MIDCOM messages carry a large set of
parameters that do not necessarily fit into an SNMP message
consisting of a single UDP packet only.
For configuration transactions the MIDCOM request message can be
modeled by one or more SNMP set transactions. The action of sending
the MIDCOM request to the middlebox is realized by writing the
parameters contained in the message to managed objects at the SNMP
agent. If necessary, the SNMP set transaction includes creating
these managed objects. If not all parameters of the MIDCOM request
message can be set by a single SNMP set transaction, then more than
one set transaction are used, see Figure 3. Completion of the last
of the SNMP transactions indicates that all required parameters are
set and that processing of the MIDCOM request message can start at
the middlebox.
Quittek, Stiemerling, Srisuresh [Page 8]
Internet-Draft MIDCOM MIB December 2007
Please note that a single SNMP set transaction consists of an SNMP
set request message and an SNMP set reply message. Both are sent as
unreliable UDP packets and may be dropped before they reach their
destination. If the SNMP set request message or the SNMP reply
message is lost, then the SNMP manager (the MIDCOM client) needs to
take action, for example by just repeating the set transaction or by
first checking the success of the initial write transaction with an
SNMP get transaction and then only repeating the SNMP set transaction
if necessary.
+--------------+ request +------------+
| MIDCOM client|-------------->| middlebox |
+--------------+ message +------------+
MIDCOM request message
+--------------+ +------------+
| | SNMP set | |
| |-------------->| |
| | message | |
| | | |
| | SNMP set | |
| |<--------------| |
| | reply message | |
| SNMP manager | | SNMP agent |
| | SNMP set | |
| |- - - - - - - >| |
| | message | |
| | | |
| | SNMP set | |
| |< - - - - - - -| |
| | reply message | |
| | | |
| | . . . | |
+--------------+ +------------+
Implementation of MIDCOM request message
by one or more SNMP set transactions
Figure 3: MIDCOM request message
mapped to SNMP set transactions
The MIDCOM reply message can be modeled in two ways. The first way
is an SNMP Notification Class operation optionally followed by one or
more SNMP get transactions as shown in Figure 4. The MIDCOM server
informs the MIDCOM client about the end of processing the request by
Quittek, Stiemerling, Srisuresh [Page 9]
Internet-Draft MIDCOM MIB December 2007
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 get transactions
Figure 4: MIDCOM reply message
mapped to SNMP notification and optional get transactions
The second way replaces the SNMP Notification Class operation by a
polling operation of the SNMP manager. The manager polls status
information at the SNMP agent using SNMP get transactions until it
detects the end of the processing of the request. Then it uses one
Quittek, Stiemerling, Srisuresh [Page 10]
Internet-Draft MIDCOM MIB December 2007
or more SNMP get transaction to receive all of the reply parameters.
Note that this second way requires more SNMP operations, but is more
reliable than the first way using an SNMP Notification Class
operation.
4.2.3. Monitoring Transactions
The realization of MIDCOM monitoring transactions in terms of SNMP
transactions is simpler. The request message is very short and just
specifies a piece of information that the MIDCOM client wants to
retrieve.
+--------------+ request +------------+
| |-------------->| |
| | message | |
| MIDCOM client| | middlebox |
| | reply | |
| |<--------------| |
+--------------+ message +------------+
MIDCOM monitoring transaction
+--------------+ +------------+
| | SNMP get | |
| |-------------->| |
| | message | |
| | | |
| | SNMP get | |
| |<--------------| |
| | reply message | |
| SNMP manager | | SNMP agent |
| | SNMP get | |
| |- - - - - - - >| |
| | message | |
| | | |
| | SNMP get | |
| |< - - - - - - -| |
| | reply message | |
| | | |
| | . . . | |
+--------------+ +------------+
Implementation of MIDCOM monitoring transaction
by one or more SNMP get messages
Figure 5: MIDCOM monitoring transaction
mapped to SNMP get transactions
Quittek, Stiemerling, Srisuresh [Page 11]
Internet-Draft MIDCOM MIB December 2007
Since monitoring is a strength of SNMP, there are sufficient means to
realize MIDCOM monitoring transactions simpler than MIDCOM
configuration transactions.
All MIDCOM monitoring transactions can be realized as a sequence of
SNMP get transactions. The number of SNMP get transactions required
depends on the amount of information to be retrieved.
4.2.4. Atomicity of MIDCOM Transactions
Given the realizations of MIDCOM transactions by means of SNMP
transactions, atomicity of the MIDCOM transactions is not fully
guaranteed anymore. However, this section shows that atomicity
provided by the MIB module specified in section 9 is still sufficient
for meeting the MIDCOM requirements specified in [RFC3304].
4.2.4.1. Asynchronous MIDCOM Transactions
There are two asynchronous MIDCOM transactions: Asynchronous Session
Termination (AST) and Asynchronous policy Rule Event (ARE). The very
static realization of MIDCOM sessions in the MIDCOM-MIB, as described
by section 4.1, does not anymore support the asynchronous termination
of a session. Therefore, the AST transaction is not modeled. For
the ARE, atomicity is maintained, because it is modeled by a single
atomic SNMP notification transaction.
In addition, the MIDCOM-MIB supports an Asynchronous Group Event
transaction which is an aggregation of a set of ARE transactions.
Also this MIDCOM transaction is implemented by a single SNMP
transaction.
4.2.4.2. Session Establishment and Termination Transactions
The MIDCOM-MIB models MIDCOM sessions in a very static way. The only
dynamic actions within these transactions are enabling and disabling
the generation of SNMP notifications at the SNMP agent.
For the Session Establishment (SE) transaction the MIDCOM client
first reads the middlebox capabilities. It is not relevant whether
or not this action is atomic because a dynamic change of the
middlebox capabilities is not to be expected. Therefore, also non-
atomic implementations of this action are acceptable.
Then the MIDCOM agent needs to enable generation of SNMP
notifications at the middlebox. This can be realized by writing to a
single managed object in the SNMP-NOTIFICATION-MIB [RFC3413]. But
even other implementations are acceptable, because atomicity is not
required for this step.
For the Session Termination (ST) transaction the only required action
Quittek, Stiemerling, Srisuresh [Page 12]
Internet-Draft MIDCOM MIB December 2007
is disabling the generation of SNMP notifications at the middlebox.
As for the SE transaction, this action can be realized atomically by
using the SNMP-NOTIFICATION-MIB, but also other implementations are
acceptable because atomicity is not required for this action.
4.2.4.3. Monitoring Transactions
Potentially, the monitoring transactions Policy Rule List (PRL),
Policy Rule Status (PRS), Group List (GL), and Group Status (GS) are
not atomic, because these transactions may be implemented by more
than one SNMP get 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 the request message and the reply
message. The request parameters can be transmitted by a single SNMP
set request message and the reply parameters can be transmitted by a
single SNMP notification message. In order to prevent idempotency
problems by retransmitting an SNMP request after a lost SNMP reply,
it is RECOMMENDED that either snmpSetSerialNo (see [RFC3418]) is
included in the corresponding SNMP SET request or the value of the
SNMP retransmission timer is lower than the smallest requested
lifetime value. The same recommendation applies to the smallest
requested value for the midcomRuleStorageTime. MIDCOM client
implementations MAY completely avoid this problem by configuring
their SNMP stack such that no retransmissions are sent.
4.2.4.5. Transactions Establishing New Policy Rules
Analogous to the monitoring transactions, the atomicty may not be
given for Policy Reserve Rule (PRR) and Policy Enable Rule (PER)
Quittek, Stiemerling, Srisuresh [Page 13]
Internet-Draft MIDCOM MIB December 2007
transactions. Both transactions are potentially implemented using
more than one SNMP set and get operations for obtaining transaction
reply parameters. The solution for this loss of atomicity is the
same as for the monitoring transactions.
There is an additional atomicity problem for PRR and PER. If
transferring request parameters requires more than a single set
operation, then there is the potential problem that multiple MIDCOM
clients sharing the same permissions are able to access the same
policy rule. In this case a client could alter request parameters
already set by another client before the first client could complete
the request. However, this is acceptable since usually only one
agent is creating a policy rule and filling it subsequently. It can
also be assumed that in most cases where clients share permissions,
they act in a more or less coordinated way avoiding such
interferences.
All atomicity problems caused by using multiple SNMP set transactions
for implementing the MIDCOM request message can be avoided by
transferring all request parameters with a single SNMP set
transaction.
4.2.5. Access Control
Since SNMP does not offer per-session authentication and
authorization, authentication and authorization are performed per
SNMP message sent from the MIDCOM client to the middlebox.
For each transaction, the MIDCOM client has to authenticate itself as
an authenticated principal, such as a USM user. Then the principal's
access rights to all resources affected by the transaction are
checked. Access right control is realized by configuring the access
control mechanisms, such as VACM, at the SNMP agent.
4.3. Access Control Policies
Potentially, a middlebox has to control access for a large set of
MIDCOM clients and to a large set of policy rules configuring
firewall pinholes and NAT bindings. Therefore it can be beneficial
to use access control policies for specifying access control rules.
Generating, provisioning and managing these policies 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, for
example, the SNMP agent's View-based Access Control Model (VACM).
The mechanisms of access control models, such as VACM, allow an
access control policy system to enforce MIDCOM client authentication
Quittek, Stiemerling, Srisuresh [Page 14]
Internet-Draft MIDCOM MIB December 2007
rules and general access control of MIDCOM clients to middlebox
control.
The mechanisms of VACM can be used to enforce access control of
authenticated clients to MIDCOM-MIB policy rules based on the concept
of ownership. For example, an access control policy can specify that
MIDCOM-MIB policy rules owned by user A, cannot be accessed at all by
user B, can be read by user C, and can be read and modified by user
D.
Further access control policies can control access to concrete
middlebox resources. These are enforced, when a MIDCOM request is
processed. For example an authenticated MIDCOM client may be
authorized to request new MIDCOM policies to be established, but only
for certain IP address ranges. The enforcement of this kind of
policies may not be realizable using available SNMP mechanisms, but
needs to be performed by the individual MIB module implementation.
Quittek, Stiemerling, Srisuresh [Page 15]
Internet-Draft MIDCOM MIB December 2007
5. Structure of the MIB module
The MIB module defined in section 9 contains three kinds of managed
objects:
- Transaction objects
Transaction objects are required for implementing the MIDCOM
protocol requirements defined in [RFC3304] and the MIDCOM
protocol semantics defined in [I-D.ietf-midcom-rfc3989-bis].
- Configuration objects
Configuration objects can be used for retrieving middlebox
capability information (mandatory) and for setting parameters of
the implementation of transaction objects (optional).
- Monitoring objects
The optional monitoring objects that provide information about
used resources and about MIDCOM transaction statistics.
The transaction objects are organized in two tables: the
midcomRuleTable and the midcomGroupTable. Entity relationships of
entries of these tables and the midcomResourceTable from the
monitoring objects are illustrated by Figure 6.
+--------------------+
| midcomRuleEntry |
| indexed by |
| midcomRuleOwner |
| midcomGroupIndex |
| midcomRuleIndex |
+--------------------+
1...n | | 1
| |
1 | | 1
+--------------------+ +---------------------+
| midcomGroupEntry | | midcomResourceEntry |
| indexed by | | indexed by |
| midcomRuleOwner | | midcomRuleOwner |
| midcomGroupIndex | | midcomGroupIndex |
+--------------------+ | midcomRuleIndex |
+---------------------+
| | |
| | |
v v v
NAT Firewall other
MIB MIB MIB
Figure 6: Entity relationships of table entries
Quittek, Stiemerling, Srisuresh [Page 16]
Internet-Draft MIDCOM MIB December 2007
A MIDCOM client can create and delete entries in the midcomRuleTable.
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. MIDCOM clients
can group policy rules for various purposes. For example, they can
assign a unique value for the midcomGroupIndex to all rules belonging
to a single application or an application session served by the
MIDCOM agent.
The midcomResourceTable augments the midcomRuleTable by information
on the relationship of entries of the midcomRuleTable to resources
listed in other MIB modules, such as the NAT MIB [RFC4008].
5.1. Transaction Objects
The transaction objects are structured according to the MIDCOM
semantics described in [I-D.ietf-midcom-rfc3989-bis] into two
subtrees, one for policy rule control and one for policy rule group
control.
5.1.1. midcomRuleTable
The midcomRuleTable contains information about policy rules including
policy rules to be established, policy rules for which establishing
failed, established policy rules and terminated policy rules.
Entries in this table are indexed by the combination of
midcomRuleOwner, midcomGroupIndex and midcomRuleIndex. The
midcomRuleOwner is the owner of the rule; the midcomGroupIndex is the
index of the group of which the policy rule is a member.
midcomRuleOwner is of type SnmpAdminString, a textual convention that
allows for use of the SNMPv3 View-Based Access Control Model (VACM
[RFC3415]) and allows a management application to identify its
entries.
Entries in this table are created by writing to midcomRuleRowStatus.
Entries are removed, when both, their midcomRuleLifetime and
midcomRuleStorageTime, are timed out by counting down to 0. A MIDCOM
client can explicitly remove an entry by setting midcomRuleLifetime
and midcomRuleStorageTime to 0.
The table contains the following columnar objects:
o midcomRuleIndex
The index of this entry must be unique in combination with the
midcomRuleOwner and the midcomGroupIndex of the entry.
Quittek, Stiemerling, Srisuresh [Page 17]
Internet-Draft MIDCOM MIB December 2007
o midcomRuleAdminStatus
For establishing a new policy rule, a set of objects in this
entry needs to be written first. These objects are the request
parameters. Then, by writing either reserve(1) or enable(2) to
this object, the MIDCOM MIB implementation is triggered to start
processing the parameters and tries to establish the specified
policy rule.
o midcomRuleOperStatus
This read-only object indicates the current status of the entry.
The entry may have an initializing state, it may have a
transient state while processing requests, it may have an error
state after a request was rejected, it may have a state where a
policy rule is established, or it may have a terminated state.
o midcomRuleStorageType
This object indicates whether or not the policy rule is stored
as volatile, non-volatile, or permanent. Depending on the
MIDCOM MIB implementation this object may be writable.
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
Quittek, Stiemerling, Srisuresh [Page 18]
Internet-Draft MIDCOM MIB December 2007
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 [I-D.ietf-midcom-rfc3989-bis]. Each of them identifies
either a communication endpoint at an internal or external device or
an allocated address at the middlebox.
+----------+ +----------+
| internal | A0 A1 +-----------+ A2 A3 | external |
| endpoint +----------+ middlebox +----------+ endpoint |
+----------+ +-----------+ +----------+
Figure 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.
Quittek, Stiemerling, Srisuresh [Page 19]
Internet-Draft MIDCOM MIB December 2007
The MIDCOM-MIB requires the MIDCOM client to specify address tuples
A0 and A3. This might be a problem for applications that are not
designed in a firewall-friendly way. An example is a FTP application
that uses the PORT command (instead of the recommended PASV command).
The problem only occurs when the middlebox offers twice-NAT
functionality and it can be fixed following recommendations for
firewall-friendly communication.
5.1.2. midcomGroupTable
The midcomGroupTable has an entry per existing policy rule group.
Entries 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 midcomRuleOwner of the rules that belong
to the group and by a specific midcomGroupIndex. This allows each
midcomRuleOwner to maintain its own independent group name space.
An entry of the table contains the following objects:
o midcomGroupIndex
The index of this entry must be unique in combination with the
midcomRuleOwner of the entry.
o midcomGroupLifetime
This object indicates the maximum of the remaining lifetimes of
all established policy rules that are members of the group. The
MIDCOM client can change the remaining lifetime of all member
policies by writing to this object.
5.2. Configuration Objects
The configuration subtree contains middlebox capability and
configuration information. Some of the contained objects are
(optionally) writable and can also be used for configuring the
middlebox service.
The capabilities subtree contains some general capability information
and detailed information per supported IP interface. The
midcomConfigFirewallTable can be used to configure how the MIDCOM MIB
implementation creates firewall rules in its firewall modules.
Note that typically, configuration objects are not intended to be
written by MIDCOM clients. In general, write access to these objects
needs to be restricted more strictly than write access to transaction
objects.
Quittek, Stiemerling, Srisuresh [Page 20]
Internet-Draft MIDCOM MIB December 2007
5.2.1. Capabilities
Information on middlebox capabilities, i.e. capabilities of the
MIDCOM MIB implementation, is provided by the midcomCapabilities
subtree of managed objects. The following objects are defined:
o midcomConfigMaxLifetime
This object indicates the maximum lifetime that this middlebox
allows policy rules to have.
o midcomConfigPersistentRules
This is a boolean object indicating whether or not the middlebox
is capable of storing policy rules persistently.
Further capabilities are provided by the midcomConfigIfTable per IP
interface. This table contains just two objects. The first one is a
BITS object called midcomConfigIfBits containing the following bit
values:
o ipv4 and ipv6
These two bit values provide information on which IP versions
are supported by the middlebox at the indexed interface.
o addressWildcards and portWildcards
These two bit values provide information on wildcarding
supported by the middlebox at the indexed interface.
o firewall and nat
These two bit values provide information on availability of
firewall and NAT functionality at the indexed interface.
o portTranslation, protocolTranslation, and twiceNat
These three bit values provide information on the kind of NAT
functionality available at the indexed interface.
o inside
This bit indicates whether or not the indexed interface is an
inside interface with respect to NAT functionality.
The second object called midcomConfigIfEnabled indicates whether 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
Quittek, Stiemerling, Srisuresh [Page 21]
Internet-Draft MIDCOM MIB December 2007
firewall implementation. Particularly, the priority used for MIDCOM-
MIB policy rules can be configured. For a single firewall
implementation at a particular IP interface, all MIDCOM-MIB policy
rules are realized as firewall rules with the same priority. Also a
firewall rule group name can be configured. The table is indexed by
the IP interface index.
An entry of the table contains the following objects:
o midcomConfigFirewallGroupId
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 objects are structured into two subtrees: the resource
subtree and the statistics subtree. The resource subtree provides
information about which resources are used by which policy rule. The
statistics subtree provide statistics about the usage of transaction
objects.
5.3.1. midcomResourceTable
Information about resource usage per policy rule is provided by the
midcomResourceTable. Each entry in the midcomResourceTable describes
resource usage of exactly one policy rule.
Resources are NAT resources and firewall resources, depending on the
type of middlebox. Used NAT resources include NAT bindings and NAT
sessions. NAT address mappings are not covered. For firewalls,
firewall filter rules are considered as resources.
The values provided by the following objects on NAT binds and NAT
sessions may refer to the detailed resource usage description in the
NAT-MIB module [RFC4008].
The values provided by the following objects on firewall rules may
refer to more detailed firewall resource usage descriptions in other
MIB modules.
Entries in the midcomResourceTable are only valid if the
midcomRuleOperStatus object of the corresponding entry in the
midcomRuleTable has a value of either reserved(7) or enabled(8).
An entry of the table contains the following objects:
Quittek, Stiemerling, Srisuresh [Page 22]
Internet-Draft MIDCOM MIB December 2007
o midcomRscNatInternalAddrBindMode
This object indicates whether the binding of the internal
address is an address NAT binding or an address-port NAT
binding.
o midcomRscNatInternalAddrBindId
This object identifies the NAT binding for the internal address
in the NAT engine.
o midcomRscNatExternalAddrBindMode
This object indicates whether the binding of the external
address is an address NAT binding or an address-port NAT
binding.
o midcomRscNatExternalAddrBindId
This object identifies the NAT binding for the external address
in the NAT engine.
o midcomRscNatSessionId1
This object links to the first NAT session associated with one
of the above NAT bindings.
o midcomRscNatSessionId2
This object links to the optional second NAT session associated
with one of the above NAT bindings.
o midcomRscFirewallRuleId
The firewall rule for this policy rule.
The MIDCOM MIB module does not require a middlebox to implement
further specific middlebox (NAT, firewall, etc.) MIB modules as, for
example, the NAT MIB module [RFC4008].
The resource identifiers in midcomResourceTable may be vendor
proprietary in the cases where the middlebox does not implement the
NAT-MIB [RFC4008] or a firewall MIB. The MIDCOM MIB module affects
NAT binding and sessions, as well as firewall pinholes. It is
intentionally not specified in the MIDCOM MIB module how these NAT
and firewall resources are allocated and managed, since this depends
on the MIDCOM MIB implementation and middlebox's capabilities.
However, the midcomResourceTable is useful for understanding which
resources are affected by which MIDCOM MIB transaction.
The midcomResourceTable is beneficial to the middlebox administrator
in that the table lists all MIDCOM transactions and the middlebox
specific resources 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
Quittek, Stiemerling, Srisuresh [Page 23]
Internet-Draft MIDCOM MIB December 2007
middlebox resources so as to satisfy the sometimes overlapping
requirements on the same resource from multiple MIDCOM clients.
Managing these resources is not a trivial task for MIDCOM MIB
implementers. It is possible that different MIDCOM-MIB policy rules
owned by different MIDCOM clients share a NAT binding or a firewall
rule. Then common properties, for example, the lifetime of the
resource, need to be managed such that all clients are served well
and changes to these resources need to be communicated to all
affected clients. Also dependencies between resources, for example,
the precedence order of firewall rules, need to be considered
carefully in order to avoid that different policy rules - potentially
owned by different clients - influence each other.
MIDCOM clients may use the midcomResourceTable of the MIDCOM MIB
module in conjunction with the NAT MIB module [RFC4008] to determine
which resources of the NAT are used for MIDCOM. The NAT MIB module
stores the configured NAT bindings and sessions and MIDCOM clients
can use the information of the midcomResourceTable to sort out those
NAT resources that are used by the MIDCOM MIB module.
5.3.2. midcomStatistics
The statistics subtree contains a set of non-columnar objects that
provide 'MIDCOM protocol statistics' i.e. statistics about the usage
of transaction objects.
o midcomCurrentOwners
This object indicates the number of different values for
midcomRuleOwner for all current entries in the midcomRuleTable.
o midcomOwnersTotal
This object indicates the summarized number of all different
values that occured for midcomRuleOwner in the midcomRuleTable
current and in the past.
o midcomTotalRejectedRuleEntries
This object indicates the total number of failed attempts to
create an entry in the midcomRuleTable.
o midcomCurrentRulesIncomplete
This object indicates the total number of policy rules that have
not been fully loaded into a table row of the midcomRuleTable.
o midcomTotalIncorrectReserveRules
This object indicates the total number of policy reserve rules
that were rejected because the request was incorrect.
o midcomTotalRejectedReserveRules
This object indicates the total number of policy reserve rules
Quittek, Stiemerling, Srisuresh [Page 24]
Internet-Draft MIDCOM MIB December 2007
that were failed while being processed.
o midcomCurrentActiveReserveRules
This object indicates the number of currently active policy
reserve rules in the midcomRuleTable.
o midcomTotalExpiredReserveRules
This object indicates the total number of expired policy reserve
rules.
o midcomTotalTerminatedOnRqReserveRules
This object indicates the total number of policy reserve rules
that were terminated on request.
o midcomTotalTerminatedReserveRules
This object indicates the total number of policy reserve rules
that were terminated, but not on request.
o midcomTotalIncorrectEnableRules
This object indicates the total number of policy enable rules
that were rejected because the request was incorrect.
o midcomTotalRejectedEnableRules
This object indicates the total number of policy enable rules
that were failed while being processed.
o midcomCurrentActiveEnableRules
This object indicates the number of currently active policy
enable rules in the midcomRuleTable.
o midcomTotalExpiredEnableRules
This object indicates the total number of expired policy enable
rules.
o midcomTotalTerminatedOnRqEnableRules
This object indicates the total number of policy enable rules
that were terminated on request.
o midcomTotalTerminatedEnableRules
This object indicates the total number of policy enable rules
that were terminated, but not on request.
5.4. Notifications
For informing MIDCOM clients about state changes of MIDCOM-MIB
implementations, three notifications can be used. They notify the
MIDCOM client about state changes of individual policy rules or of
groups of policy rules, respectively. Different notifications are
used for different kinds of transactions.
Quittek, Stiemerling, Srisuresh [Page 25]
Internet-Draft MIDCOM MIB December 2007
For asynchronous transactions unsolicited notifications are used.
The only asynchronous transaction that needs to be modeled by the
MIDCOM-MIB is the Asynchronous Policy Rule Event (ARE). The ARE may
be caused by the expiration of a policy rule lifetime, the expiration
of the idle time or due to an internal change in policy rule lifetime
by the MIDCOM-MIB implementation for whatever reason.
For configuration transactions solicited notifications are used.
This concerns the Policy Reserve Rule (PRR) transaction, the Policy
Enable Rule (PER) transaction, the Policy Rule Lifetime Change (RLC)
transaction, and the Group Lifetime Change (GLC) transaction.
The separation between unsolicited and solicited notifications gives
the implementer of a MIDCOM client some freedom to make design
decisions on how to model the MIDCOM reply message as described at
the end of section 4.2.2. Depending on the choice, processing of
solicited notifications may not be required. In such a case,
delivery of solicited notification may be disabled, for example, by
an appropriate configuration of the snmpNotifyFilterTable such that
solicited notifications are filtered differently to unsolicited
notifications.
o midcomUnsolicitedRuleEvent
This notification can be generated for indicating the change of
a policy rule's state or lifetime. It is used for performing
the ARE transaction.
o midcomSolicitedRuleEvent
This notification can be generated for indicating the requested
change of a policy rule's state or lifetime. It is used for
performing PRR, PER and RLC transactions.
o midcomSolicitedGroupEvent
This notification can be generated for indicating the requested
change of a policy rule group's lifetime. It is used for
performing the GLC transaction.
Quittek, Stiemerling, Srisuresh [Page 26]
Internet-Draft MIDCOM MIB December 2007
6. Recommendations for Configuration and Operation
Configuring MIDCOM-MIB security is highly sensitive for obvious
reasons. This section gives recommendations for securely configuring
the SNMP agent acting as MIDCOM server. In addition, recommendations
for avoiding idempotency problems are given and restrictions of
MIDCOM-MIB applicabiltiy to a special set of applications is
discussed.
6.1. Security Model Configuration
Since controlling firewalls and NATs is highly sensitive, it is
RECOMMENDED that SNMP Command Responders implementing the MIDCOM-MIB
module use the authPriv security level for all users that may access
managed objects of the MIDCOM-MIB module.
6.2. VACM Configuration
Entries in the midcomRuleTable and the midcomGroupTable provide
information about existing firewall pinholes and/or NAT sessions.
They also could be used for manipulating firewall pinholes and/or NAT
sessions. Therefore access control to these objects is essential and
should be restrictive.
It is RECOMMENDED that SNMP Command Responders instantiating an
implementation of the MIDCOM-MIB module use VACM for controlling
access to managed objects in the midcomRuleTable and the
midcomGroupTable.
It is further RECOMMENDED, that individual MIDCOM clients, acting as
SNMP Command Generators, only have access to an entry in the
midcomRuleTable, the midcomResourceTable, or the midcomGroupTable, if
they created the entry directly in the midcomRuleTable or indirectly
in the midcomGroupTable and midcomResourceTable. Exceptions to this
recommendation are situations where access by multiple MIDCOM clients
to managed objects is explicitly required. One example is fail-over
for MIDCOM agents where the stand-by MIDCOM agent needs the same
access rights to managed objects as the currently active MIDCOM
agent. Another example is a supervisor MIDCOM agent that monitors
activities of other MIDCOM agents and/or may be used by network
management systems to modify entries in tables of the MIDCOM-MIB.
For this reason, all three tables listed above have the
midcomRuleOwner as initial index. It is RECOMMENDED that MIDCOM
clients acting as SNMP Command Generator have access to the
midcomRuleTable and the midcomGroupTable restricted to entries with
the initial index matching either their SNMP securityName or their
VACM groupName. It is RECOMMENDED that they do not have access to
entries in these tables with initial indices other than their SNMP
securityName or their VACM groupName. It is RECOMMENDED that this
Quittek, Stiemerling, Srisuresh [Page 27]
Internet-Draft MIDCOM MIB December 2007
VACM configuration is applied to read access, write access, and
notify access for all objects in the midcomRuleTable and the
midcomGroupTable.
Note that less restrictive access right MAY be granted to other
users, for example, to a network management application, that
monitors MIDCOM policy rules.
6.3. Notification Configuration
For each MIDCOM client that has access to the midcomRuleTable, a
notification target SHOULD be configured at a Command Responder
instantiating an implementation of the MIDCOM-MIB. It is RECOMMENDED
that such a configuration be retrievable from the Command Responder
via the SNMP-TARGET-MIB [RFC3413].
For each entry of the snmpTargetAddrTable that is related to a MIDCOM
client, there SHOULD be an individual corresponding entry in the
snmpTargetParamsTable.
An implementation of the MIDCOM-MIB SHOULD also implement the SNMP-
NOTIFICATION-MIB [RFC3413]. An instance of an implementation of the
MIDCOM-MIB SHOULD have an individual entry in the
snmpNotifyFilterProfileTable for each MIDCOM client that has access
to the midcomRuleTable.
An instance of an implementation of the MIDCOM-MIB SHOULD allow
MIDCOM clients to start and stop the generation of notifications
targeted at themselves. This SHOULD be realized by giving the MIDCOM
clients write access to the snmpNotifyFilterTable. If appropriate
entries of the snmpNotifyFilterTable are established in advance, then
this can be achieved by granting MIDCOM clients write access only to
the columnar object snmpNotifyFilterType.
It is RECOMMENDED that VACM is configured such that each MIDCOM agent
can only access entries in the snmpTargetAddrTable, the
snmpTargetParamsTable, the snmpNotifyFilterProfileTable, and the
snmpFilterTable that concern that particular MIDCOM agent.
Typically, read access to the snmpTargetAddrTable, the
snmpTargetParamsTable, and the snmpNotifyFilterProfileTable is
sufficient. Write access may be required for objects of the
snmpFilterTable.
6.4. Simultaneous Access
Situations with two MIDOCM clients simultaneously modifying the same
policy rule should be avoided. For each entry in the midcomRuleTable
there should be only one client at a time that modifies it. If two
MIDCOM clients share the same midcomRuleOwner index of the
midcomRuleTable, then conflicts can be avoided, for example, by
Quittek, Stiemerling, Srisuresh [Page 28]
Internet-Draft MIDCOM MIB December 2007
- scheduling access times, as for example in the fail-over case,
- using different midcomGroupIndex values per client, or
- using non overlapping intervals for values of the
midcomRuleIndex per client.
6.5. Avoiding Idempotency Problems
As already discussed in section 4.2.4.4, the following recommendation
is given for avoiding idempotency problems.
In general, idempotency problems can be solved by including
snmpSetSerialNo (see [RFC3418]) in SNMP SET requests.
In case this feature is not used, it is RECOMMENDED that the value of
the SNMP retransmission timer of a MIDCOM client (acting as SNMP
Command Generator) is lower than the smallest requested value for any
rule lifetime or rule idle time in order to prevent idempotency
problems with setting midcomRuleLifetime and midcomRuleMaxIdleTime
when retransmitting an SNMP SET request after a lost SNMP reply.
MIDCOM client implementations MAY completely avoid this problem by
configuring their SNMP stack such that no retransmissions are sent.
Similar considerations apply to MIDOM-MIB implementations acting as
Notification Originator when sending a notification
(midcomUnsolicitedRuleEvent, midcomSolicitedRuleEvent or
midcomSolicitedGroupEvent) containing the remaining lifetime of a
policy rule or a policy rule group, respectively.
6.6. Interface Indexing Problems
A well known problem of MIB modules is indexing IP interfaces after a
re-initialization of the managed device. The index for interfaces
provided by the ifTable (see IF-MIB in RFC2863) may change during re-
initialization, for example, when physical interfaces are added or
removed.
The MIDCOM MIB module uses the interface index for indicating at
which interface which policy rule is (or is to be) applied. Also
this index is used for indicating how policy rules are prioritized at
certain interfaces. The MIDCOM MIB module specification requires
that information provided is always correct. This implies that after
re-initialization interface index values of policy rules or firewall
configurations may have changed even though they still refer to the
same interface as before the re-initialization.
MIDCOM client implementation need to be aware of this potential
behavior. It is RECOMMENDED that before writing the value or using
the value of indices that depend on the ifTable, that the MIDCOM
client checks if the middlebox has been re-initialized recently.
Quittek, Stiemerling, Srisuresh [Page 29]
Internet-Draft MIDCOM MIB December 2007
MIDCOM MIB module implementations MUST track interface changes of IP
interface indices in the ifTable. This implies that after a re-
initialization of a middlebox, a MIDCOM MIB implementation MUST make
sure that each instance of an interface index in the MIDCOM MIB
tables, still points to the same interface as before the re-
initialization. For any instance for which this is not possible, all
affected entries in tables of the MIDCOM MIB module MUST be either
terminated, disabled, or deleted, as specified in the DESCRIPTION
clause of the respective object. This concerns all objects in the
MIDCOM MIB module that are of type InterfaceIndexOrZero.
6.7. Applicability Restrictions
As already discussed in section 5.1.1, the MIDCOM-MIB requires the
MIDCOM client to specify address tuples A0 and A3. This can be a
problem for applications that do not have this information available
when they need to configure the middlebox. For some applications
there are usage scenarios where address information is only available
for a single address realm, A0 and A1 in the private realm or A2 and
A3 in the public realm. An example is a FTP application using the
PORT command (instead of the PASV command). The problem occurs when
the middlebox offers twice-NAT functionality.
Quittek, Stiemerling, Srisuresh [Page 30]
Internet-Draft MIDCOM MIB December 2007
7. Usage Examples for MIDCOM Transactions
This section presents some examples that explain how a MIDCOM client
acting as SNMP manager can use the MIDCOM MIB module defined in this
memo. The purpose of these examples is to explain the steps that are
required to perform MIDCOM transactions. For each MIDCOM transaction
defined in the MIDCOM semantics [I-D.ietf-midcom-rfc3989-bis], a
sequence of SNMP operations which realizes the transaction is
described.
The examples described below are recommended procedures for MIDCOM
clients. Clients may choose to operate differently.
For example, they may choose not to receive solicited notifications
on completion of a transaction, but to poll the MIDCOM-MIB instead
until the transaction is completed. This can be achieved by
performing step 2 of the SE transaction (see below) differently. The
MIDCOM agent then creates an entry in the snmpNotifyFilterTable such
that only the midcomUnsolicitedRuleEvent may pass the filter and is
sent to the MIDCOM client. In this case, the PER, PRR, and RLC
transactions require a polling loop wherever in the example below the
MIDCOM client waits for a notification.
7.1. Session Establishment (SE)
The MIDCOM-MIB realizes most properties of MIDCOM sessions in a very
static way. Only the generation of notifications targeted at the
MIDCOM client is enabled by the client for session establishment.
1. The MIDCOM client checks the middlebox capabilities by reading
objects in the midcomCapabilitiesGroup.
2. The MIDCOM client enables generation of notifications on events
concerning the policy rules controlled by the client. If the
SNMP-NOTIFICATION-MIB is supported as recommended by section 6.3
of this document, then the agent just has to change the value of a
object snmpNotifyFilterType in the corresponding entry of the
snmpNotifyFilterTable from included(1) to excluded(2).
7.2. Session Termination (ST)
For terminating a session, the MIDCOM client just disables the
generation of notifications for this client.
1. The MIDCOM client disables generation of notifications on events
concerning the policy rules controlled by the client. If the
SNMP-NOTIFICATION-MIB is supported as recommended by section 6.3
of this document, then the agent just has to change the value of a
object snmpNotifyFilterType in the corresponding entry of the
snmpNotifyFilterTable from included(1) to excluded(2).
Quittek, Stiemerling, Srisuresh [Page 31]
Internet-Draft MIDCOM MIB December 2007
7.3. Policy Reserve Rule (PRR)
This example explains steps that may be performed by a MIDCOM client
to establish a policy reserve rule.
1. The MIDCOM client creates a new entry in the midcomRuleTable by
writing to midcomRuleRowStatus. The chosen value for index object
midcomGroupIndex determines the group membership of the created
rule. Note that choosing an unused value for midcomGroupIndex
creates a new entry in the midcomGroupTable.
2. The MIDCOM client sets the following objects in the new entry of
the midcomRuleTable to specify all request parameters of the PRR
transaction:
- midcomRuleMaxIdleTime
- midcomRuleInterface
- midcomRuleTransportProtocol
- midcomRulePortRange
- midcomRuleInternalIpVersion
- midcomRuleExternalIpVersion
- midcomRuleInternalIpAddr
- midcomRuleInternalIpPrefixLength
- midcomRuleInternalPort
- midcomRuleLifetime
Note, that several of these parameters have default values that
can be used.
3. The MIDCOM client sets the midcomRuleAdminStatus objects in the
new row of the midcomRuleTable to reserve(1).
4. The MIDCOM client awaits a midcomSolicitedRuleEvent notification
concerning the new policy rule in the midcomRuleTable. Waiting
for the notification is timed out after a pre-selected maximum
waiting time. In case of a timeout while waiting for the
notification or if the client does not use notifications, the
MIDCOM client retrieves the status of the midcomRuleEntry by one
or more SNMP get operation.
5. After receiving the midcomSolicitedRuleEvent 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.
Quittek, Stiemerling, Srisuresh [Page 32]
Internet-Draft MIDCOM MIB December 2007
6. Optionally, after receiving the midcomSolicitedRuleEvent
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.
7.4. Policy Enable Rule (PER) after PRR
This example explains steps that may be performed by a MIDCOM client
to establish a policy enable rule after a corresponding policy
reserve rule was already established.
1. The MIDCOM client sets the following objects in the row of the
established PRR in the midcomRuleTable to specify all request
parameters of the PER transaction:
- 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 midcomSolicitedRuleEvent notification
concerning the new row in the midcomRuleTable. Waiting for the
notification is timed out after a pre-selected maximum waiting
time. In case of a timeout while waiting for the notification or
if the client does not use notifications, the MIDCOM client
retrieves the status of the midcomRuleEntry by one or more SNMP
get operation.
4. After receiving the midcomSolicitedRuleEvent notification, the
MIDCOM client checks the lifetime value carried by the
notification. If it is greater than 0, the MIDCOM client reads
all positive reply parameters of the PER transaction:
- midcomRuleInsideIpAddr
- midcomRuleInsidePort
- midcomRuleMaxIdleTime
If the lifetime equals 0, then the MIDCOM client reads the
midcomRuleOperStatus and the midcomRuleError in order to analyze
the failure reason.
Quittek, Stiemerling, Srisuresh [Page 33]
Internet-Draft MIDCOM MIB December 2007
5. Optionally, after receiving the midcomSolicitedRuleEvent
notification with a lifetime value greater than 0 the MIDCOM
client may check midcomResourceTable for the allocated middlebox
resources for this policy enable rule.
7.5. Policy Enable Rule (PER) without previous PRR
This example explains steps that may be performed by a MIDCOM client
to establish a policy enable rule for which no PRR transaction has
been performed before.
1. Identical to step 1 for PRR (section 7.3).
2. Identical to step 2 for PRR (section 7.3).
3. The MIDCOM client sets the following objects in the new row of the
midcomRuleTable to specify all request parameters of the PER
transaction:
- 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 4 for PRR (section 7.3).
6. After receiving the midcomSolicitedRuleEvent 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
If the lifetime equals 0, then MIDCOM client reads the
Quittek, Stiemerling, Srisuresh [Page 34]
Internet-Draft MIDCOM MIB December 2007
midcomRuleOperStatus and the midcomRuleError in order to analyze
the failure reason.
7. Optionally, after receiving the midcomSolicitedRuleEvent
notification with a lifetime value greater than 0 the MIDCOM
client may check midcomResourceTable for the allocated middlebox
resources for this policy enable rule.
7.6. Policy Rule Lifetime Change (RLC)
This example explains steps that may be performed by a MIDCOM client
to change the lifetime of a policy rule. Changing the lifetime to 0
implies terminating the policy rule.
1. The MIDCOM client issues a set-request for writing the desired
lifetime to the midcomRuleLifetime object in the corresponding row
of the midcomRuleTable. This does not have any effect if the
lifetime is already expired.
2. The MIDCOM client awaits a midcomSolicitedRuleEvent notification
concerning the corresponding row in the midcomRuleTable. Waiting
for the notification is timed out after a pre-selected maximum
waiting time. In case of a timeout while waiting for the
notification or if the client does not use notifications, the
MIDCOM client retrieves the status of the midcomRuleEntry by one
or more SNMP get operation.
3. After receiving the midcomSolicitedRuleEvent notification MIDCOM
client checks the lifetime value carried by the notification.
7.7. Policy Rule List (PRL)
The SNMP agent can browse the list of policy rules by browsing the
midcomRuleTable. For each observed row in this table, the SNMP agent
should check the midcomRuleOperStatus in order to find out, if the
row contains information about an established policy rule or of a
rule that is under construction or already terminated.
7.8. Policy Rule Status (PRS)
The SNMP agent can retrieve all status information and properties of
a policy rule by reading the managed objects in the corresponding row
of the midcomRuleTable.
7.9. 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 or the
expiration of the idle time. But beyond this, the MIDCOM MIB
implementation may terminate a policy rule at any time. In all cases
Quittek, Stiemerling, Srisuresh [Page 35]
Internet-Draft MIDCOM MIB December 2007
two steps are required for performing this transaction:
1. The MIDCOM MIB implementation sends a midcomUnsolicitedRuleEvent
notification containing a lifetime value of 0 to the MIDCOM client
owning the rule.
2. If the midcomRuleStorageTime object in the corresponding row of
the midcomRuleTable has a value of 0 then the MIDCOM MIB
implementation removes the row from the table. Otherwise, it sets
in this row the midcomRuleLifetime object to 0 and changes the
midcomRuleOperStatus object. If the event was triggered by policy
lifetime expiration, then the midcomRuleOperStatus is set to
timedOut(9), otherwise, it is set to terminated(11).
7.10. Group Lifetime Change (GLC)
This example explains steps that may be performed by a MIDCOM client
to change the lifetime of a policy rule group. Changing the lifetime
to 0 implies terminating all member policies of the group.
1. The MIDCOM client issues a set-request for writing the desired
lifetime to the midcomGroupLifetime object in the corresponding
row of the midcomGroupTable.
2. The MIDCOM client waits for a midcomSolicitedGroupEvent
notification concerning the corresponding row in the
midcomGroupTable. Waiting for the notification is timed out after
a pre-selected maximum waiting time. In case of a timeout while
waiting for the notification or if the client does not use
notifications, the MIDCOM client retrieves the status of the
midcomGroupEntry by one or more SNMP get operation.
3. After receiving the midcomSolicitedRuleEvent notification MIDCOM
client checks the lifetime value carried by the notification.
7.11. Group List (GL)
The SNMP agent can browse the list of policy rule groups by browsing
the midcomGroupTable. For each observed row in this table, the SNMP
agent should check the midcomGroupLifetime in order to find out, if
the group does contain established policies.
7.12. Group Status (GS)
The SNMP agent can retrieve all member policies of a group by
browsing the midcomRuleTable using the midcomGroupIndex of the
particular group. For retrieving the remaining lifetime of the
group, the SNMP agent reads the midcomGroupLifetime object in the
corresponding row of the midcomGroupTable.
Quittek, Stiemerling, Srisuresh [Page 36]
Internet-Draft MIDCOM MIB December 2007
8. Usage Examples for Monitoring Objects
This section presents some examples that explain how a MIDCOM client
can use the midcomResourceTable to correlate policy rules with the
used middlebox resources. One example is given for middleboxes
implementing the NAT MIB and another one is given for firewalls.
8.1. Monitoring NAT Resources
When a rule in midcomRuleTable is executed, it directly impacts the
middlebox resources. The midcomResourceTable provides the
information on the relationships between the MIDCOM-MIB policy rules
and the middlebox resources used for enforcing these rules.
A MIDCOM-MIB policy rule will cause the creation or modification of
up to two NAT bindings and up to two NAT sessions. Two NAT bindings
are impacted in the case of a session being subject to twice-NAT.
Two NAT bindings may also be impacted when midcomRulePortRange is set
to pair(2) in the policy rule. In the majority of cases, where
traditional NAT is implemented, only a single NAT binding may be
adequate. Note, however, 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 the NAT MIB module is not implemented at the
middlebox.
The impact of MIDCOM rules on the NAT resources is important because
a MIDCOM rule 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. The lifetime parameter in the MIDCOM rule directly impacts
the lifetime of all the impacted NAT BIND and NAT session objects.
8.2. Monitoring Firewall Resources
When a MIDCOM-MIB policy rule is established at a middlebox with
firewall capabilities, this may lead to the creation of one or more
new firewall rules. Note that in general a single firewall rule per
MIDCOM-MIB policy rule will be sufficient. For each policy rule, a
MIDCOM client can explore the corresponding firewall filter rule by
Quittek, Stiemerling, Srisuresh [Page 37]
Internet-Draft MIDCOM MIB December 2007
reading the midcomResourceEntry in the midcomResourceTable that
corresponds to the midcomRuleEntry describing the rule. The
identification of the firewall filter rule is stored in object
midcomRscFirewallRuleId. The value of midcomRscFirewallRuleId may
correspond directly to any firewall filter rule number or to an entry
in a locally available firewall MIB module.
Quittek, Stiemerling, Srisuresh [Page 38]
Internet-Draft MIDCOM MIB December 2007
9. Definitions
The following MIB module imports from [RFC2578], [RFC2579],
[RFC2580], [RFC2863], [RFC3411], [RFC4001], and [RFC4008].
MIDCOM-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE,
NOTIFICATION-TYPE, Unsigned32,
Counter32, Gauge32, mib-2
FROM SNMPv2-SMI -- RFC2578
TEXTUAL-CONVENTION, TruthValue,
StorageType, RowStatus
FROM SNMPv2-TC -- RFC2579
MODULE-COMPLIANCE, OBJECT-GROUP,
NOTIFICATION-GROUP
FROM SNMPv2-CONF -- RFC2580
SnmpAdminString
FROM SNMP-FRAMEWORK-MIB -- RFC3411
InetAddressType, InetAddress,
InetPortNumber,
InetAddressPrefixLength
FROM INET-ADDRESS-MIB -- RFC4001
InterfaceIndexOrZero
FROM IF-MIB -- RFC2863
NatBindIdOrZero
FROM NAT-MIB; -- RFC4008
midcomMIB MODULE-IDENTITY
LAST-UPDATED "200708091011Z" -- August 09, 2007
ORGANIZATION "IETF Middlebox Communication Working Group"
CONTACT-INFO
"WG charter:
http://www.ietf.org/html.charters/midcom-charter.html
Mailing Lists:
General Discussion: midcom@ietf.org
To Subscribe: midcom-request@ietf.org
In Body: subscribe your_email_address
Co-editor:
Juergen Quittek
NEC Europe Ltd.
Quittek, Stiemerling, Srisuresh [Page 39]
Internet-Draft MIDCOM MIB December 2007
Network Laboratories
Kurfuersten-Anlage 36
69115 Heidelberg
Germany
Tel: +49 6221 4342-115
Email: quittek@netlab.nec.de
Co-editor:
Martin Stiemerling
NEC Europe Ltd.
Network Laboratories
Kurfuersten-Anlage 36
69115 Heidelberg
Germany
Tel: +49 6221 4342-113
Email: stiemerling@netlab.nec.de
Co-editor:
P. Srisuresh
Caymas Systems, Inc.
1179-A North McDowell Blvd.
Petaluma, CA 94954
USA
Tel: +1 707 283-5063
Email: srisuresh@yahoo.com"
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 kinds of objects:
- transaction objects required according to the MIDCOM
protocol requirements defined in RFC 3304 and according
to the MIDCOM protocol semantics defined in RFC 3989,
- configuration objects that can be used for retrieving or
setting parameters of the implementation of transaction
objects,
- optional monitoring objects that provide information
about used resource and statistics
The transaction objects, are organized in two subtrees:
- objects modeling MIDCOM policy rules in the
midcomRuleTable
- objects modeling MIDCOM policy rule groups in the
midcomGroupTable
Note that typically, configuration objects are not intended
Quittek, Stiemerling, Srisuresh [Page 40]
Internet-Draft MIDCOM MIB December 2007
to be written by MIDCOM clients. In general, write access
to these objects needs to be restricted more strictly than
write access to objects in the transaction subtrees.
Copyright (C) The Internet Society (2006). 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 "200708091011Z" -- August 09, 2007
DESCRIPTION "Initial version, published as RFC yyyy."
-- RFC Ed.: replace yyyy with actual RFC number and
-- remove this notice
::= { mib-2 xxxxx }
-- RFC Ed.: replace xxxxx with IANA-assigned number and
-- remove this note
--
-- main components of this MIB module
--
midcomNotifications OBJECT IDENTIFIER ::= { midcomMIB 0 }
midcomObjects OBJECT IDENTIFIER ::= { midcomMIB 1 }
midcomConformance OBJECT IDENTIFIER ::= { midcomMIB 2 }
-- Transaction objects required according to the MIDCOM
-- protocol requirements defined in RFC 3304 and according to
-- the MIDCOM protocol semantics defined in RFC 3989
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 transaction
-- objects (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 two groups:
-- - the policy rules group containing objects that model
-- policy rules, and
-- - the group group containing objects modeling policy rule
Quittek, Stiemerling, Srisuresh [Page 41]
Internet-Draft MIDCOM MIB December 2007
-- groups.
--
-- Policy rule subtree
--
-- 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 midcomRuleOwner, 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 { midcomRuleOwner, midcomGroupIndex, midcomRuleIndex }
::= { midcomRuleTable 1 }
MidcomRuleEntry ::= SEQUENCE {
midcomRuleOwner SnmpAdminString,
midcomRuleIndex Unsigned32,
midcomRuleAdminStatus INTEGER,
midcomRuleOperStatus INTEGER,
midcomRuleStorageType StorageType,
midcomRuleStorageTime Unsigned32,
midcomRuleError SnmpAdminString,
midcomRuleInterface InterfaceIndexOrZero,
midcomRuleFlowDirection INTEGER,
midcomRuleMaxIdleTime Unsigned32,
midcomRuleTransportProtocol Unsigned32,
midcomRulePortRange INTEGER,
Quittek, Stiemerling, Srisuresh [Page 42]
Internet-Draft MIDCOM MIB December 2007
midcomRuleInternalIpVersion InetAddressType,
midcomRuleExternalIpVersion InetAddressType,
midcomRuleInternalIpAddr InetAddress,
midcomRuleInternalIpPrefixLength InetAddressPrefixLength,
midcomRuleInternalPort InetPortNumber,
midcomRuleExternalIpAddr InetAddress,
midcomRuleExternalIpPrefixLength InetAddressPrefixLength,
midcomRuleExternalPort InetPortNumber,
midcomRuleInsideIpAddr InetAddress,
midcomRuleInsidePort InetPortNumber,
midcomRuleOutsideIpAddr InetAddress,
midcomRuleOutsidePort InetPortNumber,
midcomRuleLifetime Unsigned32,
midcomRuleRowStatus RowStatus
}
midcomRuleOwner OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE (0..32))
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The manager who owns this row in the midcomRuleTable.
This object SHOULD uniquely identify an authenticated
MIDCOM client. This object is part of the table index to
allow for the use of the SNMPv3 View-Based Access Control
Model (RFC 3415, VACM)."
::= { midcomRuleEntry 1 }
midcomRuleIndex OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The value of this object must be unique in
combination with the values of the objects
midcomRuleOwner and midcomGroupIndex in this row."
::= { midcomRuleEntry 3 }
midcomRuleAdminStatus OBJECT-TYPE
SYNTAX INTEGER {
reserve(1),
enable(2),
notSet(3)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The value of this object indicates the desired status of
the policy rule. See the definition of midcomRuleOperStatus
Quittek, Stiemerling, Srisuresh [Page 43]
Internet-Draft MIDCOM MIB December 2007
for a description of the values.
When a midcomRuleEntry is created without explicitly setting
this object, its value will be notSet(3).
However, a set request can only set this object to either
reserve(1) or enable(2). Attempts to set this object to
notSet(3) will always fail with an 'inconsistentValue'
error. Note that this error code is SNMP specific. If the
MIB module is used with other protocols than SNMP, errors
with similar semantics specific to those protocols should
be returned.
When the midcomRuleAdminStatus object is set, then the
MIDCOM MIB implementation will try to read the respective
relevant objects of the entry and try to achieve the
corresponding midcomRuleOperStatus.
Setting midcomRuleAdminStatus to value reserve(1) when
object midcomRuleOperStatus has a value of reserved(7)
does not have any effect on the policy rule.
Setting midcomRuleAdminStatus to value enable(2) when
object midcomRuleOperStatus has a value of enabled(8)
does not have any effect on the policy rule.
Depending on whether the midcomRuleAdminStatus is set to
reserve(1) or enable(2) several objects must be set in
advance. They serve as parameters of the policy rule to be
established
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
Quittek, Stiemerling, Srisuresh [Page 44]
Internet-Draft MIDCOM MIB December 2007
- midcomRuleFlowDirection
- midcomRuleMaxIdleTime
- midcomRuleTransportProtocol
- midcomRulePortRange
- midcomRuleInternalIpVersion
- midcomRuleExternalIpVersion
- midcomRuleInternalIpAddr
- midcomRuleInternalIpPrefixLength
- midcomRuleInternalPort
- midcomRuleExternalIpAddr
- midcomRuleExternalIpPrefixLength
- midcomRuleExternalPort
- midcomRuleLifetime
When retrieved, the object returns the last set value.
If no value has been set, it returns the default value
notSet(3)."
DEFVAL { notSet }
::= { midcomRuleEntry 4 }
midcomRuleOperStatus OBJECT-TYPE
SYNTAX INTEGER {
newEntry(1),
setting(2),
checkingRequest(3),
incorrectRequest(4),
processingRequest(5),
requestRejected(6),
reserved(7),
enabled(8),
timedOut(9),
terminatedOnRequest(10),
terminated(11),
genericError(12)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The actual status of the policy rule. The
midcomRuleOperStatus object may have the following values:
- newEntry(1) indicates that the entry in the
midcomRuleTable was created, but not modified yet.
Such an entry needs to be filled with values specifying
a request first.
- setting(2) indicates that the entry has been already
modified after generating it, but no request was made
yet.
Quittek, Stiemerling, Srisuresh [Page 45]
Internet-Draft MIDCOM MIB December 2007
- checkingRequest(3) indicates that midcomRuleAdminStatu