tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 5190

Proposed STD
Pages: 92
Top     in Index     Prev     Next
in Group Index     Prev in Group     No Next: Highest Number in Group     Group: MIDCOM

Definitions of Managed Objects for Middlebox Communication

Part 1 of 4, p. 1 to 15
None       Next RFC Part

 


Top       ToC       Page 1 
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.

Top       Page 2 
Table of Contents

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

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

Top      ToC       Page 4 
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.

Top      ToC       Page 5 
   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

Top      ToC       Page 6 
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

Top      ToC       Page 7 
   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.

Top      ToC       Page 8 
               +--------------+  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.

Top      ToC       Page 9 
   Please note that a single SNMP SET transaction consists of an SNMP
   SET request message and an SNMP SET reply message.  Both are sent as
   unreliable UDP packets and may be dropped before they reach their
   destination.  If the SNMP SET request message or the SNMP reply
   message is lost, then the SNMP manager (the MIDCOM client) needs to
   take action, for example, by just repeating the SET transaction or by
   first checking the success of the initial write transaction with an
   SNMP GET transaction and then only repeating the SNMP SET transaction
   if necessary.

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

                          MIDCOM request message


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

                 Implementation of MIDCOM request message
                   by one or more SNMP SET transactions

                     Figure 3: MIDCOM request message
                      mapped to SNMP SET transactions

   The MIDCOM reply message can be modeled in two ways.  The first way
   is an SNMP Notification Class operation optionally followed by one or
   more SNMP GET transactions as shown in Figure 4.  The MIDCOM server
   informs the MIDCOM client about the end of processing the request by
   sending an SNMP notification.  If possible, the SNMP notification

Top      ToC       Page 10 
   carries all reply parameters.  If this is not possible, then the SNMP
   manager has to perform additional SNMP GET transactions as long as
   necessary to receive all of the reply parameters.

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

                           MIDCOM reply message


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

                  Implementation of MIDCOM reply message
                          by an SNMP notification
                   and one or more SNMP GET transactions

                      Figure 4: MIDCOM reply message
         mapped to SNMP notification and optional GET transactions

   The second way replaces the SNMP Notification Class operation by a
   polling operation of the SNMP manager.  The manager polls status
   information at the SNMP agent using SNMP GET transactions until it
   detects the end of the processing of the request.  Then it uses one
   or more SNMP GET transactions to receive all of the reply parameters.
   Note that this second way requires more SNMP operations, but is more

Top      ToC       Page 11 
   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

Top      ToC       Page 12 
   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.

Top      ToC       Page 13 
   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.

Top      ToC       Page 14 
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.

Top      ToC       Page 15 
   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.



(page 15 continued on part 2)

Next RFC Part