RFC 5190

Definitions of Managed Objects for Middlebox Communication

Network Working Group J. Quittek
Request for Comments: 5190 M. Stiemerling
Category: Standards Track NEC
P. Srisuresh
Kazeon Systems
March 2008 Definitions of Managed Objects for Middlebox Communication
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes a set of managed objects that allow
configuring middleboxes, such as firewalls and network address
translators, in order to enable communication across these devices.
The definitions of managed objects in this documents follow closely
the MIDCOM semantics defined in RFC 5189.

1. Introduction
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes a set of managed objects that allow
controlling middleboxes.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. The Internet-Standard Management Framework
For a detailed overview of the documents that describe the current
Internet-Standard Management Framework, please refer to section 7 of
RFC 3410 [RFC3410].
Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. MIB objects are generally
accessed through the Simple Network Management Protocol (SNMP).
Objects in the MIB are defined using the mechanisms defined in the
Structure of Management Information (SMI). This memo specifies a MIB
module that is compliant to the SMIv2, which is described in STD 58,
RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
[RFC2580].
3. Overview
The managed objects defined in this document serve for controlling
firewalls and Network Address Translators (NATs). As defined in
[RFC3234], firewalls and NATs belong to the group of middleboxes. A
middlebox is a device on the datagram path between source and
destination, which performs other functions than just IP routing. As
outlined in [RFC3303], firewalls and NATs are potential obstacles to
packet streams, for example, if dynamically negotiated UDP or TCP
port numbers are used, as in many peer-to-peer communication
applications.
As one possible solution for this problem, the IETF MIDCOM working
group defined a framework [RFC3303], requirements [RFC3304], and
protocol semantics [RFC5189] for communication between applications
and middleboxes acting as firewalls, NATs, or a combination of both.
The MIDCOM architecture and framework define a model in which trusted
third parties can be delegated to assist middleboxes in performing
their operations, without requiring application intelligence being
embedded in the middleboxes. This trusted third party is referred to
as the MIDCOM agent. The MIDCOM protocol is defined between a MIDCOM
agent and a middlebox.

The managed objects defined in this document can be used for
dynamically configuring middleboxes on the datagram path to permit
datagrams traversing the middleboxes. This way, applications can,
for example, request pinholes at firewalls and address bindings at
NATs.
Besides managed objects for controlling the middlebox operation, this
document also defines managed objects that provide information on
middlebox resource usage (such as firewall pinholes, NAT bindings,
NAT sessions, etc.) affected by requests.
Since firewalls and NATs are critical devices concerning network
security, security issues of middlebox communication need to be
considered very carefully.
3.1. Terminology
The terminology used in this document is fully aligned with the
terminology defined in [RFC5189] except for the term 'MIDCOM agent'.
For this term, there is a conflict between the MIDCOM terminology and
the SNMP terminology. The roles of entities participating in SNMP
communication are called 'manager' and 'agent' with the agent acting
as server for requests from the manager. This use of the term
'agent' is different from its use in the MIDCOM framework: The SNMP
manager corresponds to the MIDCOM agent and the SNMP agent
corresponds to the MIDCOM middlebox, also called MIDCOM server. In
order to avoid confusion in this document specifying a MIB module, we
replace the term 'MIDCOM agent' with 'MIDCOM client'. Whenever the
term 'agent' is used in this document, it refers to the SNMP agent.
Figure 1 sketches the entities of MIDCOM in relationship to SNMP
manager and SNMP agent.
+---------+ MIDCOM +-----------+
| MIDCOM |<~ ~ ~ ~ ~ ~ ~ ~>| MIDCOM |
| Client | Transaction | middlebox |
| | | (server) |
+---------+ +-----------+
^ ^
| |
v v
+---------+ +-----------+
| SNMP | SNMP | SNMP |
| Manager |<===============>| Agent |
+---------+ Protocol +-----------+
Figure 1: Mapping of MIDCOM to SNMP

4. Realizing the MIDCOM Protocol with SNMP
In order to realize middlebox communication as described in
[RFC5189], several aspects and properties of the MIDCOM protocol need
to be mapped to SNMP capabilities and expressed in terms of the
Structure of Management Information version 2 (SMIv2).
Basic concepts to be mapped are MIDCOM sessions and MIDCOM
transactions. For both, access control policies need to be
supported.
4.1. MIDCOM Sessions
SNMP has no direct support for sessions. Therefore, they need to be
modeled. A MIDCOM session is stateful and has a context that is
valid for several transactions. For SNMP, a context is valid for a
single transaction only, for example, covering just a single
request/reply pair of messages.
Properties of sessions that are utilized by the MIDCOM semantics and
not available in SNMP need to be modeled. Particularly, the
middlebox needs to be able to authenticate MIDCOM clients, authorize
access to policy rules, and send notification messages concerning
policy rules to MIDCOM clients participating in a session. In the
MIDCOM-MIB module, authentication and access control are performed on
a per-message basis using an SNMPv3 security model, such as the
User-based Security Model (USM) [RFC3414], for authentication, and
the View-based Access Control Model (VACM) [RFC3415] for access
control. Sending notifications to MIDCOM clients is controlled by
access control models such as VACM and a mostly static configuration
of objects in the SNMP-TARGET-MIB [RFC3413] and the SNMP-
NOTIFICATION-MIB [RFC3413].
This session model is static except that the MIDCOM client can switch
on and off the generation of SNMP notifications that the middlebox
sends. Recommended configurations of VACM and the SNMP-TARGET-MIB
and the SNMP-NOTIFICATION-MIB that can serve for modeling a session
are described in detail in section 6.
4.1.1. Authentication and Authorization
MIDCOM sessions are required for providing authentication,
authorization, and encryption for messages exchanged between a MIDCOM
client and a middlebox. SNMPv3 provides these features on a per-
message basis instead of a per-session basis applying a security
model and an access control model, such as USM and VACM. Per-message

security mechanisms can be considered as overhead compared to per-
session security mechanisms, but it certainly satisfies the security
requirements of middlebox communication.
For each authenticated MIDCOM client, access to the MIDCOM-MIB,
particularly to policy rules, should be configured as part of the
VACM configuration of the SNMP agent.
4.2. MIDCOM Transactions
[RFC5189] defines the MIDCOM protocol semantics in terms of
transactions and transaction parameters. Transactions are grouped
into request-reply transactions and asynchronous transactions.
SNMP offers simple transactions that in general cannot be mapped
one-to-one to MIDCOM transactions. This section describes how the
MIDCOM-MIB module implements MIDCOM transactions using SNMP
transactions. The concerned MIDCOM transactions are asynchronous
transactions and request-reply transactions. Within the set of
request-reply transactions, we distinguish configuration transactions
and monitoring transactions, because they are implemented in slightly
different ways by using SNMP transactions.
The SNMP terminology as defined in [RFC3411] does not use the concept
of transactions, but of SNMP operations. For the considerations in
this section, we use the terms SNMP GET transaction and SNMP SET
transaction. An SNMP GET transaction consists of an SNMP Read Class
operation and an SNMP Response Class operation. An SNMP SET
transaction consists of an SNMP Write Class operation and an SNMP
Response Class operation.
4.2.1. Asynchronous Transactions
Asynchronous transactions can easily be modeled by SNMP Notification
Class operations. An asynchronous transaction contains a
notification message with one to three parameters. The message can
be realized as an SNMP Notification Class operation with the
parameters implemented as managed objects contained in the
notification.

+--------------+ notification +------------+
| MIDCOM client|<--------------| middlebox |
+--------------+ message +------------+
MIDCOM asynchronous transaction
+--------------+ SNMP +------------+
| SNMP manager |<--------------| SNMP agent |
+--------------+ notification +------------+
Implementation of MIDCOM asynchronous transaction
Figure 2: MIDCOM asynchronous transaction
mapped to SNMP Notification Class operation
One of the parameters is the transaction identifier that should be
unique per middlebox. It does not have to be unique for all
notifications sent by the particular SNMP agent, but for all sent
notifications that are defined by the MIDCOM-MIB module.
Note that SNMP notifications are usually sent as unreliable UDP
packets and may be dropped before they reach their destination. If a
MIDCOM client is expecting an asynchronous notification on a specific
transaction, it would be the job of the MIDCOM client to poll the
middlebox periodically and monitor the transaction in case
notifications are lost along the way.
4.2.2. Configuration Transactions
All request-reply transactions contain a request message, a reply
message, and potentially also a set of notifications. In general,
they cannot be modeled by just having a single SNMP message per
MIDCOM message, because some of the MIDCOM messages carry a large set
of parameters that do not necessarily fit into an SNMP message
consisting of a single UDP packet only.
For configuration transactions, the MIDCOM request message can be
modeled by one or more SNMP SET transactions. The action of sending
the MIDCOM request to the middlebox is realized by writing the
parameters contained in the message to managed objects at the SNMP
agent. If necessary, the SNMP SET transaction includes creating
these managed objects. If not all parameters of the MIDCOM request
message can be set by a single SNMP SET transaction, then more than
one SET transaction is used; see Figure 3. Completion of the last of
the SNMP transactions indicates that all required parameters are set
and that processing of the MIDCOM request message can start at the
middlebox.

Since monitoring is a strength of SNMP, there are sufficient means to
realize MIDCOM monitoring transactions simpler than MIDCOM
configuration transactions.
All MIDCOM monitoring transactions can be realized as a sequence of
SNMP GET transactions. The number of SNMP GET transactions required
depends on the amount of information to be retrieved.
4.2.4. Atomicity of MIDCOM Transactions
Given the realizations of MIDCOM transactions by means of SNMP
transactions, atomicity of the MIDCOM transactions is not fully
guaranteed anymore. However, this section shows that atomicity
provided by the MIB module specified in section 9 is still sufficient
for meeting the MIDCOM requirements specified in [RFC3304].
4.2.4.1. Asynchronous MIDCOM Transactions
There are two asynchronous MIDCOM transactions: Asynchronous Session
Termination (AST) and Asynchronous Policy Rule Event (ARE). The very
static realization of MIDCOM sessions in the MIDCOM-MIB, as described
by section 4.1, does not anymore support the asynchronous termination
of a session. Therefore, the AST transaction is not modeled. For
the ARE, atomicity is maintained, because it is modeled by a single
atomic SNMP notification transaction.
In addition, the MIDCOM-MIB supports an Asynchronous Group Event
transaction, which is an aggregation of a set of ARE transactions.
Also, this MIDCOM transaction is implemented by a single SNMP
transaction.
4.2.4.2. Session Establishment and Termination Transactions
The MIDCOM-MIB models MIDCOM sessions in a very static way. The only
dynamic actions within these transactions are enabling and disabling
the generation of SNMP notifications at the SNMP agent.
For the Session Establishment (SE) transaction, the MIDCOM client
first reads the middlebox capabilities. It is not relevant whether
or not this action is atomic because a dynamic change of the
middlebox capabilities is not to be expected. Therefore, also non-
atomic implementations of this action are acceptable.
Then, the MIDCOM agent needs to enable the generation of SNMP
notifications at the middlebox. This can be realized by writing to a
single managed object in the SNMP-NOTIFICATION-MIB [RFC3413]. But
even other implementations are acceptable, because atomicity is not
required for this step.

For the Session Termination (ST) transaction, the only required
action is disabling the generation of SNMP notifications at the
middlebox. As for the SE transaction, this action can be realized
atomically by using the SNMP-NOTIFICATION-MIB, but also other
implementations are acceptable because atomicity is not required for
this action.
4.2.4.3. Monitoring Transactions
Potentially, the monitoring transactions Policy Rule List (PRL),
Policy Rule Status (PRS), Group List (GL), and Group Status (GS) are
not atomic, because these transactions may be implemented by more
than one SNMP GET operation.
The problem that might occur is that while the monitoring transaction
is performed, the monitored items may change. For example, while
reading a long list of policies, new policies may be added and
already read policies may be deleted. This is not in line with the
protocol semantics. However, it is not in direct conflict with the
MIDCOM requirement requesting the middlebox state to be stable and
known by the MIDCOM client, because the middlebox notifies the MIDCOM
client on all changes to its state that are performed during the
monitoring transaction by sending notifications.
If the MIDCOM client receives such a notification while performing a
monitoring transaction (or shortly after completing it), the MIDCOM
client can then either repeat the monitoring transaction or integrate
the result of the monitoring transaction with the information
received via notifications during the transaction. In both cases,
the MIDCOM client will know the state of the middlebox.
4.2.4.4. Lifetime Change Transactions
For the policy Rule Lifetime Change (RLC) transaction and the Group
Lifetime Change (GLC) transaction, atomicity is maintained. They
both have very few parameters for the request message and the reply
message. The request parameters can be transmitted by a single SNMP
SET request message, and the reply parameters can be transmitted by a
single SNMP notification message. In order to prevent idempotency
problems by retransmitting an SNMP request after a lost SNMP reply,
it is RECOMMENDED that either snmpSetSerialNo (see [RFC3418]) is
included in the corresponding SNMP SET request or the value of the
SNMP retransmission timer be lower than the smallest requested
lifetime value. The same recommendation applies to the smallest
requested value for the midcomRuleStorageTime. MIDCOM client
implementations MAY completely avoid this problem by configuring
their SNMP stack such that no retransmissions are sent.

4.2.4.5. Transactions Establishing New Policy Rules
Analogous to the monitoring transactions, the atomicity may not be
given for Policy Reserve Rule (PRR) and Policy Enable Rule (PER)
transactions. Both transactions are potentially implemented using
more than one SNMP SET operation and GET operation for obtaining
transaction reply parameters. The solution for this loss of
atomicity is the same as for the monitoring transactions.
There is an additional atomicity problem for PRR and PER. If
transferring request parameters requires more than a single SET
operation, then there is the potential problem that multiple MIDCOM
clients sharing the same permissions are able to access the same
policy rule. In this case, a client could alter request parameters
already set by another client before the first client could complete
the request. However, this is acceptable since usually only one
agent is creating a policy rule and filling it subsequently. It can
also be assumed that in most cases where clients share permissions,
they act in a more or less coordinated way avoiding such
interferences.
All atomicity problems caused by using multiple SNMP SET transactions
for implementing the MIDCOM request message can be avoided by
transferring all request parameters with a single SNMP SET
transaction.
4.2.5. Access Control
Since SNMP does not offer per-session authentication and
authorization, authentication and authorization are performed per
SNMP message sent from the MIDCOM client to the middlebox.
For each transaction, the MIDCOM client has to authenticate itself as
an authenticated principal, such as a USM user. Then, the
principal's access rights to all resources affected by the
transaction are checked. Access right control is realized by
configuring the access control mechanisms, such as VACM, at the SNMP
agent.
4.3. Access Control Policies
Potentially, a middlebox has to control access for a large set of
MIDCOM clients and to a large set of policy rules configuring
firewall pinholes and NAT bindings. Therefore, it can be beneficial
to use access control policies for specifying access control rules.
Generating, provisioning, and managing these policies are out of
scope of this MIB module.

However, if such an access control policy system is used, then the
SNMP agent acts as a policy enforcement point. An access control
policy system must transform all active policies into configurations
of, for example, the SNMP agent's View-based Access Control Model
(VACM).
The mechanisms of access control models, such as VACM, allow an
access control policy system to enforce MIDCOM client authentication
rules and general access control of MIDCOM clients to middlebox
control.
The mechanisms of VACM can be used to enforce access control of
authenticated clients to MIDCOM-MIB policy rules based on the concept
of ownership. For example, an access control policy can specify that
MIDCOM-MIB policy rules owned by user A cannot be accessed at all by
user B, can be read by user C, and can be read and modified by user
D.
Further access control policies can control access to concrete
middlebox resources. These are enforced, when a MIDCOM request is
processed. For example, an authenticated MIDCOM client may be
authorized to request new MIDCOM policies to be established, but only
for certain IP address ranges. The enforcement of this kind of
policies may not be realizable using available SNMP mechanisms, but
needs to be performed by the individual MIB module implementation.