RFC 5190
Definitions of Managed Objects for Middlebox Communication
RFC 5190: Definitions of Managed Objects for Middlebox Communication ✨🎀
okay bestie, let's get into it 💅 this is the RFC that defines the SNMP MIB objects for controlling middleboxes (firewalls and NATs) so applications can open up paths through them. it's the SNMP side of the MIDCOM work 🦋
- Number: RFC 5190
- Title: Definitions of Managed Objects for Middlebox Communication
- Authors: J. Quittek and M. Stiemerling (both from NEC), and P. Srisuresh (from Kazeon Systems)
- Category: Standards Track
- Date: March 2008
- Obsoletes / Updates: the header doesn't list anything it obsoletes or updates 🌸
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
okay so this memo defines a chunk of the Management Information Base (MIB) for network management protocols in the Internet community. the big idea is a set of managed objects that let you configure middleboxes, like firewalls and network address translators, so that communication can get through them 🧚 the object definitions here follow the MIDCOM semantics from RFC 5189 pretty closely 💖
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
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 ........................................901. Introduction 🌈
so this memo is the MIB portion for network management protocols in the Internet community. the managed objects here let you control 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]. these are the official requirement words, so they keep their exact meaning here, no vibes-based interpretation 🫶
2. The Internet-Standard Management Framework 👑
if you want the full tour of the current Internet-Standard Management Framework, check out section 7 of RFC 3410 [RFC3410] 📚
managed objects live in a virtual information store called the Management Information Base, or MIB. MIB objects are usually accessed through the Simple Network Management Protocol (SNMP). the objects get defined using the Structure of Management Information (SMI) rules. this memo specifies a MIB module that is compliant with 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 in this document are for controlling firewalls and Network Address Translators (NATs). as defined in [RFC3234], firewalls and NATs are middleboxes. a middlebox is a device sitting on the datagram path between source and destination that does more than just IP routing 🧚
as outlined in [RFC3303], firewalls and NATs can be obstacles for packet streams. this happens when dynamically negotiated UDP or TCP port numbers are involved, like in lots of peer-to-peer apps 🙈
the IETF MIDCOM working group came up with a fix. they defined a framework [RFC3303], requirements [RFC3304], and protocol semantics [RFC5189] for communication between applications and middleboxes that act as firewalls, NATs, or both. the idea is that trusted third parties can be delegated to help middleboxes do their job, so the application smarts don't have to live inside the middleboxes. this trusted third party is called the MIDCOM agent, and the MIDCOM protocol runs between a MIDCOM agent and a middlebox 💅
the managed objects here can be used to dynamically configure middleboxes on the datagram path so datagrams can get through. this way, applications can request pinholes at firewalls and address bindings at NATs 🔥
this document also defines managed objects that report on middlebox resource usage (like firewall pinholes, NAT bindings, NAT sessions, and so on) affected by those requests 💖
and because firewalls and NATs are critical for network security, security issues in middlebox communication need to be considered very carefully. like, seriously 😭
3.1. Terminology 🎀
the terminology in this document matches [RFC5189] exactly, except for one term: 'MIDCOM agent'. there's a clash between MIDCOM terminology and SNMP terminology here 💀
in SNMP, the entities are called 'manager' and 'agent', and the agent acts as the server for requests from the manager. so SNMP's use of 'agent' is different from how MIDCOM uses it. the SNMP manager corresponds to the MIDCOM agent, and the SNMP agent corresponds to the MIDCOM middlebox, also called the MIDCOM server 🌸
to avoid confusion in a document that specifies a MIB module, this memo replaces 'MIDCOM agent' with 'MIDCOM client'. wherever 'agent' shows up in this document, it means the SNMP agent 🧚
Figure 1 shows how the MIDCOM entities line up with the 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 SNMP4. Realizing the MIDCOM Protocol with SNMP 🍓
to make middlebox communication work as described in [RFC5189], a bunch of MIDCOM protocol aspects and properties need to be mapped onto SNMP capabilities. they also need to be expressed using the Structure of Management Information version 2 (SMIv2) 💜
the basic concepts being mapped are MIDCOM sessions and MIDCOM transactions. for both of them, access control policies need to be supported ✨
4.1. MIDCOM Sessions ✨
Okay so SNMP has zero built-in sessions 💀, which means we have to build one ourselves. A MIDCOM session is stateful and its context sticks around for several transactions. SNMP contexts only last for a single transaction, like one request and one reply and then it's over 🫠.
The MIDCOM session needs some extra stuff that SNMP doesn't give you. The middlebox has to be able to authenticate MIDCOM clients, authorize access to policy rules, and send notification messages about policy rules to the MIDCOM clients in a session. In the MIDCOM-MIB module, authentication and access control happen on every single message. Authentication uses an SNMPv3 security model such as the User-based Security Model (USM) [RFC3414], and access control uses the View-based Access Control Model (VACM) [RFC3415]. Sending notifications to MIDCOM clients is handled by access control models like VACM, plus a mostly static setup of objects in the SNMP-TARGET-MIB [RFC3413] and the SNMP-NOTIFICATION-MIB [RFC3413] 🎀.
The session model is basically static, with one exception: the MIDCOM client can turn on and off the SNMP notifications the middlebox sends. Recommended VACM, SNMP-TARGET-MIB, and SNMP-NOTIFICATION-MIB setups that can model a session are explained 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 does all of this per message instead of per session, using a security model and an access control model like USM and VACM. Yes, per-message security can be seen as more overhead than per-session security, but it totally covers the security needs of middlebox communication 💅.
For each authenticated MIDCOM client, access to the MIDCOM-MIB (especially the 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 come in two flavors: request-reply transactions and asynchronous transactions 💜.
SNMP has simple transactions that usually can't be mapped one-to-one onto MIDCOM transactions. This section explains how the MIDCOM-MIB module uses SNMP transactions to implement MIDCOM transactions. The ones we care about are asynchronous transactions and request-reply transactions. Inside the request-reply group, we split things up into configuration transactions and monitoring transactions, because SNMP handles them in slightly different ways ✨.
SNMP itself, as defined in [RFC3411], doesn't talk about transactions. It talks about operations instead. So for this section we use the terms SNMP GET transaction and SNMP SET transaction. An SNMP GET transaction is one SNMP Read Class operation plus one SNMP Response Class operation. An SNMP SET transaction is one SNMP Write Class operation plus one SNMP Response Class operation 🍓.
4.2.1. Asynchronous Transactions 📣
Asynchronous transactions map really neatly onto SNMP Notification Class operations. An asynchronous transaction carries a notification message with one to three parameters. The message can be done as an SNMP Notification Class operation, where the parameters are managed objects inside 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 operationOne of the parameters is the transaction identifier, which should be unique per middlebox. It doesn't need to be unique across every notification the SNMP agent sends. It only needs to be unique across all the notifications that the MIDCOM-MIB module defines 🔍.
Heads up, though: SNMP notifications are usually sent as unreliable UDP packets, so they can get dropped before they arrive. If a MIDCOM client is waiting for an asynchronous notification on a specific transaction, it's on the client to poll the middlebox now and then and keep an eye on the transaction, just in case a notification gets lost along the way 😭.
4.2.2. Configuration Transactions ⚙️
Every request-reply transaction has a request message, a reply message, and maybe a set of notifications too. In general, you can't model these with just one SNMP message per MIDCOM message. Some MIDCOM messages carry a big pile of parameters, and those don't always fit into one SNMP message that's a single UDP packet 🙈.
For configuration transactions, the MIDCOM request message can be modeled as one or more SNMP SET transactions. Sending the MIDCOM request to the middlebox happens by writing the message's parameters into managed objects on the SNMP agent. If needed, the SNMP SET transaction also creates those managed objects. If a single SNMP SET transaction can't set all the parameters of the MIDCOM request message, then you use more than one SET transaction, as shown in Figure 3. Once the last of those SNMP transactions finishes, that tells you all the required parameters are set and the middlebox can start processing the MIDCOM request message 🎯.
Just so you know, one SNMP SET transaction is an SNMP SET request message plus an SNMP SET reply message. Both get sent as unreliable UDP packets and can be dropped before they reach their destination. If the SNMP SET request message or the SNMP SET reply message gets lost, then the SNMP manager (the MIDCOM client) has to do something about it. It can just repeat the SET transaction, or it can first check whether the original write worked using an SNMP GET transaction, and only repeat the SNMP SET transaction if it's actually needed 🧐.
+--------------+ 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 transactionsThe MIDCOM reply message can be modeled in two different 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 lets the MIDCOM client know it's done processing the request by sending an SNMP notification. If possible, that notification carries all the reply parameters. If that's not possible, the SNMP manager has to keep doing SNMP GET transactions for as long as it takes to get all 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 transactionsThe second way swaps out the SNMP Notification Class operation for polling. The SNMP manager keeps polling status information on the SNMP agent with SNMP GET transactions until it spots the end of the request processing. After that, it does one or more SNMP GET transactions to grab all the reply parameters. Heads up: this second way needs more SNMP operations, but it's more reliable than the first way that uses an SNMP Notification Class operation 💖.
4.2.3. Monitoring Transactions ✨
okay so monitoring transactions are the easy ones bestie 🧚 the request message is super short and literally just names the piece of info the MIDCOM client wants to grab 💅
+--------------+ 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 transactionsmonitoring is literally SNMP's whole thing 🔥 so there are plenty of ways to make MIDCOM monitoring transactions simpler than MIDCOM configuration transactions 🦋
every MIDCOM monitoring transaction can be realized as a sequence of SNMP GET transactions 🌸 how many you end up needing depends on how much info you're trying to retrieve 📚
4.2.4. Atomicity of MIDCOM Transactions 💜
so once MIDCOM transactions are realized with SNMP transactions, atomicity is not fully guaranteed anymore 😭 but the vibe is still good: this section shows that the atomicity provided by the MIB module specified in section 9 is still sufficient to meet the MIDCOM requirements from [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 super static way MIDCOM sessions are modeled in the MIDCOM-MIB (see section 4.1) doesn't support asynchronous termination of a session anymore, so the AST transaction is not modeled 🙈 the ARE keeps its atomicity though, because it's modeled as one single atomic SNMP notification transaction ✨
the MIDCOM-MIB also supports an Asynchronous Group Event transaction, which is an aggregation of a set of ARE transactions 👑 and this one is implemented by a single SNMP transaction too 💖
4.2.4.2. Session Establishment and Termination Transactions 🎀
the MIDCOM-MIB models MIDCOM sessions in a very static way 💅 the only dynamic stuff happening in these transactions is turning on and off the generation of SNMP notifications at the SNMP agent 🔥
for the Session Establishment (SE) transaction, the MIDCOM client first reads the middlebox capabilities 🦋 whether that's atomic doesn't really matter, because the middlebox capabilities aren't expected to change dynamically 😌 so non-atomic implementations of this action are acceptable too 🫶
then the MIDCOM agent needs to enable generation of SNMP notifications at the middlebox 🌸 you can do that by writing to a single managed object in the SNMP-NOTIFICATION-MIB [RFC3413] ✨ but other implementations are also fine, since atomicity isn't required for this step 💜
for the Session Termination (ST) transaction, the only required action is disabling generation of SNMP notifications at the middlebox 🧚 same as SE, this can be done atomically with the SNMP-NOTIFICATION-MIB, but other implementations are acceptable because atomicity isn't required for this action either 💅
4.2.4.3. Monitoring Transactions 🍓
the monitoring transactions Policy Rule List (PRL), Policy Rule Status (PRS), Group List (GL), and Group Status (GS) might not be atomic 😬 that's because each of them can be implemented with more than one SNMP GET operation 🌈
the problem is that while a monitoring transaction is running, the stuff being monitored can change 🙃 for example, while you're reading a long list of policies, new policies might get added and ones you already read might get deleted 💀 that's not in line with the protocol semantics, ngl 😭 but it's not in direct conflict with the MIDCOM requirement that the middlebox state be stable and known to the MIDCOM client, because the middlebox sends notifications to the MIDCOM client about every change to its state that happens during the monitoring transaction 🔥
if the MIDCOM client gets such a notification while performing a monitoring transaction (or shortly after finishing it), it can either repeat the monitoring transaction or merge the result with the info it got from the notifications during the transaction 👑 either way, 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 in the request and reply messages 💖 the request parameters can be sent in a single SNMP SET request message, and the reply parameters can be sent in a single SNMP notification message 🫶
to avoid idempotency problems from 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 🌸 and MIDCOM client implementations MAY avoid this problem completely by configuring their SNMP stack so that no retransmissions are sent 💅
4.2.4.5. Transactions Establishing New Policy Rules 💜
just like the monitoring transactions, atomicity may not be given for Policy Reserve Rule (PRR) and Policy Enable Rule (PER) transactions 😵 both of them could be implemented using more than one SNMP SET operation and GET operation (to get the reply parameters) 🌈 the fix for losing atomicity here is the same as for the monitoring transactions 🫶
there's an extra atomicity problem for PRR and PER 🚨 if sending the request parameters takes more than a single SET operation, then multiple MIDCOM clients sharing the same permissions could potentially access the same policy rule 👀 a client could change request parameters that another client already set before the first client finishes its request 😬 but this is considered acceptable, since usually only one agent creates a policy rule and fills it in afterwards 💅 and in most cases where clients share permissions, they tend to work in a more or less coordinated way so they don't step on each other 🤝
all the atomicity problems caused by using multiple SNMP SET transactions for the MIDCOM request message can be avoided by sending all the request parameters in a single SNMP SET transaction 🎀
4.2.5. Access Control 🔐
since SNMP doesn't offer per-session authentication and authorization, authentication and authorization are done 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 get checked 👑 access right control is set up 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 number of MIDCOM clients and for a large set of policy rules that configure firewall pinholes and NAT bindings 🔥 so it can be really helpful to use access control policies to specify access control rules 🦋 generating, provisioning, and managing these policies is out of scope for this MIB module 🙃
but if an access control policy system is used, 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, let an access control policy system 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 say 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 get enforced when a MIDCOM request is processed 🫶 for example, an authenticated MIDCOM client may be authorized to request new MIDCOM policies be established, but only for certain IP address ranges 🌸 enforcing this kind of policy may not be doable with the available SNMP mechanisms, so it needs to be handled by the individual MIB module implementation 😤💜
5. Structure of the MIB Module ✨
The MIB module defined in section 9 is packed with three kinds of managed objects, and honestly, it's giving organized 🎀:
- Transaction objects Transaction objects are REQUIRED for implementing the MIDCOM protocol requirements defined in [RFC3304] and the MIDCOM protocol semantics defined in [RFC5189].
- 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 provide information about used resources and about MIDCOM transaction statistics. 📊
Okay so the transaction objects live in two tables: the midcomRuleTable and the midcomGroupTable. Figure 6 shows how the entries in these tables, plus the midcomResourceTable from the monitoring objects, are related to each other 💅
+--------------------+
| 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 entriesA MIDCOM client can create and delete entries in the midcomRuleTable 🙌. Entries in the midcomGroupTable are generated automatically as soon as there is an entry in the midcomRuleTable using the midcomGroupIndex. The midcomGroupTable can be used as a shortcut for accessing all member rules with a single transaction, which is so efficient. 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 adding 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 [RFC5189] into two subtrees, one for policy rule control and one for policy rule group control. Two subtrees, two vibes, zero drama 💜
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. Main character energy 👑
Entries in this table are indexed by the combination of midcomRuleOwner, midcomGroupIndex, and midcomRuleIndex. The midcomRuleOwner is the owner of the rule, and 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. Bye bye, entry 👋
The table contains the following columnar objects:
- midcomRuleIndex The index of this entry MUST be unique in combination with the midcomRuleOwner and the midcomGroupIndex of the entry.
- 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. Ready, set, go 🚀
- 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. So many possible vibes 🌈
- 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. 💾
- midcomRuleStorageTime This object indicates how long the entry will still exist after entering an error state or a termination state. ⏳
- midcomRuleError This object is a string indicating the reason for entering an error state. 💀
- midcomRuleInterface This object indicates the IP interface for which enforcement of a policy rule is requested or performed, respectively. 🧚
- midcomRuleFlowDirection This object indicates a flow direction for which a policy enable rule was requested or established, respectively. ✨
- 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. Quiet too long and you're out 🙈
- midcomRuleTransportProtocol This object indicates a transport protocol for which a policy reserve rule or policy enable rule was requested or established, respectively. 🍓
- midcomRulePortRange This object indicates a port range for which a policy reserve rule or policy enable rule was requested or established, respectively. 🌸
- 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. Lots of addresses, lots of feelings 💖
A0, A1, A2, and A3 are address tuples defined according to the MIDCOM semantics [RFC5189]. 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 internal network, with respect to the middlebox.
- 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 external network, with respect to the middlebox.
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 an 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. Bestie, firewall-friendly apps are the real MVPs 🫶
5.1.2. midcomGroupTable
The midcomGroupTable has an entry per existing policy rule group. Entries in 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. No manual creating here, it's all automatic ✨
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 namespace. Everyone gets their own lane 🛣️
An entry of the table contains the following objects:
- midcomGroupIndex The index of this entry MUST be unique in combination with the midcomRuleOwner of the entry.
- 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. Settings, but make it cute ⚙️
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.
Hold up, bestie: configuration objects are usually a no-write zone for MIDCOM clients, so lock down write access harder than you would for transaction objects 🔒💅
5.2.1. Capabilities ✨
Info on middlebox capabilities, aka what the MIDCOM-MIB implementation can actually do, lives in the midcomCapabilities subtree of managed objects 🧚. Here's what's defined:
midcomConfigMaxLifetime: this is the maximum lifetime that this middlebox lets policy rules have ⏳.midcomConfigPersistentRules: a boolean that tells you whether or not the middlebox can store policy rules persistently 💾.
Okay, and there's more! Further capabilities are served up by the midcomConfigIfTable, one row per IP interface 🌈. This table only has two objects. The first is a BITS object called midcomConfigIfBits, and it holds these bit values:
ipv4andipv6: these two tell you which IP versions the middlebox supports at the indexed interface 🌐.addressWildcardsandportWildcards: these two show what wildcarding the middlebox supports at the indexed interface 🃏.firewallandnat: these two show whether firewall and NAT functionality is available at the indexed interface 🔥.portTranslation,protocolTranslation, andtwiceNat: these three show the kind of NAT functionality available at the indexed interface 💅.inside: this one tells you whether the indexed interface is an inside interface with respect to NAT functionality 🏠.
The second object, midcomConfigIfEnabled, is the one that says whether the capabilities in midcomConfigIfBits are actually available or not at the indexed IP interface. Lowkey the key pairing 🫶.
The midcomConfigIfTable uses index 0 for capabilities that are available for all interfaces 💜.
5.2.2. midcomConfigFirewallTable 🎀
The midcomConfigFirewallTable is where you configure how the policy rules created by MIDCOM clients get realized as firewall rules in a firewall implementation 🔥. The big thing here is the priority used for MIDCOM-MIB policy rules, which you can configure. For a single firewall implementation at a particular IP interface, all MIDCOM-MIB policy rules become firewall rules with the same priority 👑. You can also configure a firewall rule group name. The table is indexed by the IP interface index 🦋.
An entry of the table contains these objects:
midcomConfigFirewallGroupId: this indicates the firewall rule group that all firewall rules of the MIDCOM server get assigned to 🫧.midcomConfigFirewallPriority: this indicates the priority assigned to all firewall rules of the MIDCOM server ⭐.
5.3. Monitoring Objects 👀
The monitoring objects are split into two subtrees: the resource subtree and the statistics subtree 🌸. The resource subtree tells you which resources are used by which policy rule. The statistics subtree gives you stats about how transaction objects are being used 📊.
5.3.1. midcomResourceTable 🧾
Info about resource usage per policy rule lives in the midcomResourceTable 💖. Each entry in the midcomResourceTable describes resource usage of exactly one policy rule, no more, no less 🎯.
Resources are NAT resources and firewall resources, depending on what type of middlebox you're dealing with 🧱. Used NAT resources include NAT bindings and NAT sessions. NAT address mappings are NOT covered, so don't go looking for them here 🙅♀️. For firewalls, firewall filter rules count as resources 🛡️.
The values provided by the following objects on NAT binds and NAT sessions may refer you to the detailed resource usage description in the NAT-MIB module [RFC4008] 📚. The values on firewall rules may refer you to more detailed firewall resource usage descriptions in other MIB modules 🔍.
Entries in the midcomResourceTable are only valid if the midcomRuleOperStatus object of the matching entry in the midcomRuleTable has a value of either reserved(7) or enabled(8) ✅. Anything else and the row isn't valid, bestie 💀.
An entry of the table contains these objects:
midcomRscNatInternalAddrBindMode: this indicates whether the binding of the internal address is an address NAT binding or an address-port NAT binding 🩷.midcomRscNatInternalAddrBindId: this identifies the NAT binding for the internal address in the NAT engine 🆔.midcomRscNatExternalAddrBindMode: this indicates whether the binding of the external address is an address NAT binding or an address-port NAT binding 💜.midcomRscNatExternalAddrBindId: this identifies the NAT binding for the external address in the NAT engine 🪪.midcomRscNatSessionId1: this links to the first NAT session associated with one of the above NAT bindings 🔗.midcomRscNatSessionId2: this links to the optional second NAT session associated with one of the above NAT bindings 🧷.midcomRscFirewallRuleId: this indicates the firewall rule for this policy rule 🔥.
The MIDCOM-MIB module does NOT require a middlebox to implement any further specific middlebox MIB modules (NAT, firewall, and so on), like the NAT-MIB module [RFC4008] for example 🙃. And the resource identifiers in the midcomResourceTable may be vendor proprietary in the cases where the middlebox doesn't implement the NAT-MIB [RFC4008] or a firewall MIB 🏭. The MIDCOM-MIB module affects NAT bindings and sessions, as well as firewall pinholes 🕳️. It's intentionally NOT specified in the MIDCOM-MIB module how these NAT and firewall resources get allocated and managed, since that depends on the MIDCOM-MIB implementation and the middlebox's capabilities 🤷♀️. Still, the midcomResourceTable is super useful for figuring out which resources are affected by which MIDCOM-MIB transaction 🧠.
The midcomResourceTable is genuinely great for the middlebox administrator, because the table lists all MIDCOM transactions and the middlebox-specific resources each one refers to 🍓. For example, multiple MIDCOM clients might end up using the same NAT bind, yet each MIDCOM client might define its own Lifetime parameter and directionality for that bind, specific to its transaction 🎀. MIDCOM-MIB implementations are responsible for impacting the underlying middlebox resources so they 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, not gonna lie 😭. It's possible that different MIDCOM-MIB policy rules owned by different MIDCOM clients share a NAT binding or a firewall rule. So common properties, like the lifetime of the resource, need managing so that all clients are served well, and any changes to these resources need communicating to all affected clients 📣. Dependencies between resources also need careful thought, like the precedence order of firewall rules, so that different policy rules (potentially owned by different clients) don't end up influencing each other 🙈.
MIDCOM clients can use the midcomResourceTable of the MIDCOM-MIB module together with the NAT-MIB module [RFC4008] to figure out which NAT resources are used for MIDCOM 🔍. The NAT-MIB module stores the configured NAT bindings and sessions, and MIDCOM clients can use the info in the midcomResourceTable to sort out which of those NAT resources are used by the MIDCOM-MIB module 🗂️✨.
5.3.2. midcomStatistics 📈
The statistics subtree holds a set of non-columnar objects that provide "MIDCOM protocol statistics", i.e., statistics about how transaction objects are used 💅.
midcomCurrentOwners: this indicates the number of different values formidcomRuleOwneracross all current entries in themidcomRuleTable👑.midcomOwnersTotal: this indicates the summarized number of all the different values that have ever occurred formidcomRuleOwnerin themidcomRuleTable, current AND past 🕰️.midcomTotalRejectedRuleEntries: this indicates the total number of failed attempts to create an entry in themidcomRuleTable🥀.midcomCurrentRulesIncomplete: this indicates the total number of policy rules that have NOT been fully loaded into a table row of themidcomRuleTable🧩.midcomTotalIncorrectReserveRules: this indicates the total number of policy reserve rules that were rejected because the request was incorrect ❌.midcomTotalRejectedReserveRules: this indicates the total number of policy reserve rules that failed while being processed 😵.midcomCurrentActiveReserveRules: this indicates the number of currently active policy reserve rules in themidcomRuleTable🟢.midcomTotalExpiredReserveRules: this indicates the total number of expired policy reserve rules ⌛.midcomTotalTerminatedOnRqReserveRules: this indicates the total number of policy reserve rules that were terminated on request 🛑.midcomTotalTerminatedReserveRules: this indicates the total number of policy reserve rules that were terminated, but NOT on request 💥.midcomTotalIncorrectEnableRules: this indicates the total number of policy enable rules that were rejected because the request was incorrect 🙅♀️.midcomTotalRejectedEnableRules: this indicates the total number of policy enable rules that failed while being processed 🫠.midcomCurrentActiveEnableRules: this indicates the number of currently active policy enable rules in themidcomRuleTable💚.midcomTotalExpiredEnableRules: this indicates the total number of expired policy enable rules 🍂.midcomTotalTerminatedOnRqEnableRules: this indicates the total number of policy enable rules that were terminated on request 🙋♀️.midcomTotalTerminatedEnableRules: this indicates the total number of policy enable rules that were terminated, but NOT on request 🌪️.
5.4. Notifications 🔔
okay so, the MIDCOM-MIB has three notifications 🫶 they tell the MIDCOM client when something changes, either for one policy rule or for a whole group of them. Each kind of transaction gets its own notification, so it's always clear what happened 💅
For asynchronous transactions, the MIDCOM client gets unsolicited notifications. The only asynchronous transaction the MIDCOM-MIB needs to model is the Asynchronous Policy Rule Event (ARE) 🦋 An ARE can happen when a policy rule's lifetime runs out, when its idle time runs out, or when the MIDCOM-MIB implementation changes a policy rule's lifetime on its own for whatever reason.
For configuration transactions, the MIDCOM client gets solicited notifications ✨ These cover 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.
Splitting unsolicited from solicited notifications gives MIDCOM client implementers a lot of freedom 🌈 They get to decide how to model the MIDCOM reply message, which is covered at the end of section 4.2.2. Depending on that choice, the client might not need to process solicited notifications at all. If that's the case, delivery of solicited notifications can be turned off, for example through a suitable configuration of the snmpNotifyFilterTable, so that solicited notifications get filtered differently from unsolicited ones 🙈
midcomUnsolicitedRuleEventThis notification can be generated to indicate a change in a policy rule's state or lifetime. It is used for performing the ARE transaction. 💜midcomSolicitedRuleEventThis notification can be generated to indicate a requested change in a policy rule's state or lifetime. It is used for performing the PRR, PER, and RLC transactions. 🍓midcomSolicitedGroupEventThis notification can be generated to indicate a requested change in a policy rule group's lifetime. It is used for performing the GLC transaction. 🧚
6. Recommendations for Configuration and Operation 💅
Configuring MIDCOM-MIB security is seriously sensitive, and it's not hard to see why 😭 This section gives recommendations for configuring the SNMP agent that acts as the MIDCOM server, securely. It also covers how to avoid idempotency problems and talks about the limits of which applications the MIDCOM-MIB really fits 🎀
6.1. Security Model Configuration ✨
Controlling firewalls and NATs is highly sensitive, so it is RECOMMENDED that SNMP Command Responders implementing the MIDCOM-MIB module use the authPriv security level for all users who may access managed objects of the MIDCOM-MIB module 🔒
6.2. VACM Configuration 🌸
Entries in the midcomRuleTable and the midcomGroupTable tell you about existing firewall pinholes and/or NAT sessions. They could also be used to manipulate those firewall pinholes and/or NAT sessions 😳 So access control for these objects is essential, and it should be restrictive.
It is RECOMMENDED that SNMP Command Responders instantiating an implementation of the MIDCOM-MIB module use VACM to control access to managed objects in the midcomRuleTable and the midcomGroupTable 🛡️
It is further RECOMMENDED that individual MIDCOM clients, acting as SNMP Command Generators, only get access to an entry in the midcomRuleTable, the midcomResourceTable, or the midcomGroupTable if they created that entry directly in the midcomRuleTable or indirectly in the midcomGroupTable and midcomResourceTable. There are exceptions to this, for 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 one. Another example is a supervisor MIDCOM agent that monitors what other MIDCOM agents are doing and/or that network management systems can use to modify entries in tables of the MIDCOM-MIB 👑
This is why all three tables listed above have midcomRuleOwner as their initial index 🧁 It is RECOMMENDED that MIDCOM clients acting as SNMP Command Generators have access to the midcomRuleTable and the midcomGroupTable restricted to entries whose initial index matches either their SNMP securityName or their VACM groupName. It is RECOMMENDED that they do not have access to entries in these tables with any other initial indices. It is RECOMMENDED that this 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 rights 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 can be retrieved 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 a matching individual 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 aimed at themselves. This SHOULD be done by giving MIDCOM clients write access to the snmpNotifyFilterTable. If the appropriate entries of the snmpNotifyFilterTable are set up in advance, then this can be achieved by granting MIDCOM clients write access only to the columnar object snmpNotifyFilterType 🪄
It is RECOMMENDED that VACM be configured so each MIDCOM agent can only access the 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 enough. Write access may be needed for objects in the snmpFilterTable 🌷
6.4. Simultaneous Access 🚦
Situations where two MIDCOM clients modify the same policy rule at the same time 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:
- scheduling access times, as in the fail-over case;
- using different
midcomGroupIndexvalues per client; or - using non-overlapping intervals for values of the
midcomRuleIndexper client. 🍭
6.5. Avoiding Idempotency Problems 🔁
As already discussed in section 4.2.4.4, here's the recommendation for avoiding idempotency problems 💖
In general, idempotency problems can be solved by including snmpSetSerialNo (see [RFC3418]) in SNMP SET requests ✅
If this feature is not used, it is RECOMMENDED that the value of the SNMP retransmission timer of a MIDCOM client (acting as an SNMP Command Generator) is lower than the smallest requested value for any rule lifetime or rule idle time. This prevents idempotency problems with setting midcomRuleLifetime and midcomRuleMaxIdleTime when an SNMP SET request is retransmitted after a lost SNMP reply ⏱️
MIDCOM client implementations MAY completely avoid this problem by configuring their SNMP stack so that no retransmissions are sent 🙌
Similar considerations apply to MIDCOM-MIB implementations acting as Notification Originators when they send 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 with MIB modules is indexing IP interfaces after the managed device re-initializes 😩 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 to say which policy rule is (or is going to be) applied at which interface. The same index is also used to show how policy rules are prioritized at certain interfaces. The MIDCOM-MIB module specification requires that the information provided is always correct ✔️ That means 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 🫠
MIDCOM client implementations need to be aware of this potential behavior 👀 It is RECOMMENDED that, before writing or using the value of indices that depend on the ifTable, the MIDCOM client checks whether the middlebox has been re-initialized recently.
MIDCOM-MIB module implementations MUST track changes to IP interface indices in the ifTable 🕵️♀️ That means 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 where this is not possible, all affected entries in tables of the MIDCOM-MIB module MUST be terminated, disabled, or deleted, as specified in the DESCRIPTION clause of the respective object. This applies to 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 don't have this information 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 an FTP application using the PORT command (instead of the PASV command). The problem shows up when the middlebox offers twice-NAT functionality 🌍
7. Usage Examples for MIDCOM Transactions ✨
okay so this section is the fun part bestie 🎀 It shows how a MIDCOM client acting as an SNMP manager can use the MIDCOM-MIB module from this memo. The goal is to walk through the exact steps for each MIDCOM transaction in the MIDCOM semantics [RFC5189], and every transaction gets its own sequence of SNMP operations 💅
The examples below are recommended procedures for MIDCOM clients. Clients may choose to operate differently 🦋
For example, a client might not want solicited notifications when a transaction finishes, and would rather poll the MIDCOM-MIB until it's done 👀 To do that, you change step 2 of the SE transaction (see below). The MIDCOM agent then creates an entry in the snmpNotifyFilterTable so that only the midcomUnsolicitedRuleEvent gets through the filter and is sent to the MIDCOM client. In that setup, the PER, PRR, and RLC transactions need a polling loop wherever the example below has the client waiting for a notification 🔁
7.1. Session Establishment (SE)
The MIDCOM-MIB handles most properties of MIDCOM sessions in a very static way 🧊 The only thing the client has to switch on for session establishment is the generation of notifications aimed at the MIDCOM client.
- The MIDCOM client checks the middlebox capabilities by reading objects in the midcomCapabilitiesGroup.
- 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)
To end a session, the MIDCOM client just turns off notification generation for itself 🌙
- 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). 🫶
7.3. Policy Reserve Rule (PRR)
This example explains the steps a MIDCOM client may take to set up a policy reserve rule 🌸
- The MIDCOM client creates a new entry in the midcomRuleTable by writing to midcomRuleRowStatus. The value you pick for the index object midcomGroupIndex decides which group the new rule belongs to. Note that choosing an unused value for midcomGroupIndex creates a new entry in the midcomGroupTable 🧩
- 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. 🍓
- The MIDCOM client sets the midcomRuleAdminStatus objects in the new row of the midcomRuleTable to reserve(1). 📌
- 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 ⏳ If the wait times out, or if the client doesn't use notifications at all, the MIDCOM client retrieves the status of the midcomRuleEntry with one or more SNMP GET operations.
- 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 PRR transaction:
- midcomRuleOutsideIpAddr
- midcomRuleOutsidePort
- midcomRuleMaxIdleTime
- midcomRuleLifetime
If the lifetime equals 0, then the MIDCOM client reads the midcomRuleOperStatus and the midcomRuleError to figure out why it failed 😭
- Optionally, after receiving the midcomSolicitedRuleEvent notification with a lifetime value greater than 0, the MIDCOM client may check the midcomResourceTable for the middlebox resources allocated for this policy reserve rule 🔍 Note that PRR doesn't necessarily allocate any middlebox resource visible in the NAT-MIB module or in a firewall MIB module, since it only does a reservation. 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 the steps a MIDCOM client may take to set up a policy enable rule after a matching policy reserve rule already exists 💜
- 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. 🎀
- The MIDCOM client sets the midcomRuleAdminStatus objects in the row of the established PRR in the midcomRuleTable to enable(1). ✅
- 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 ⏳ If the wait times out, or if the client doesn't use notifications, the MIDCOM client retrieves the status of the midcomRuleEntry with one or more SNMP GET operations.
- 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 to analyze the failure reason 💀
- Optionally, after receiving the midcomSolicitedRuleEvent notification with a lifetime value greater than 0, the MIDCOM client may check the midcomResourceTable for the allocated middlebox resources for this policy enable rule 🌈
7.5. Policy Enable Rule (PER) without Previous PRR
This example explains the steps a MIDCOM client may take to set up a policy enable rule when no PRR transaction was done beforehand 🦄
- Identical to step 1 for PRR (section 7.3).
- Identical to step 2 for PRR (section 7.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. 🍒
- The MIDCOM client sets the midcomRuleAdminStatus objects in the new row of the midcomRuleTable to enable(1). 🚀
- Identical to step 4 for PRR (section 7.3).
- 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 PRR transaction:
- midcomRuleInsideIpAddr
- midcomRuleInsidePort
- midcomRuleOutsideIpAddr
- midcomRuleOutsidePort
- midcomRuleMaxIdleTime
If the lifetime equals 0, then the MIDCOM client reads the midcomRuleOperStatus and the midcomRuleError to analyze the failure reason 🫠
- Optionally, after receiving the midcomSolicitedRuleEvent notification with a lifetime value greater than 0, the MIDCOM client may check the midcomResourceTable for the allocated middlebox resources for this policy enable rule 🌟
7.6. Policy Rule Lifetime Change (RLC)
This example explains the steps a MIDCOM client may take to change how long a policy rule lasts ⏰ Setting the lifetime to 0 means terminating the policy rule 🛑
- The MIDCOM client issues a SET request to write the desired lifetime to the midcomRuleLifetime object in the corresponding row of the midcomRuleTable. This does nothing if the lifetime has already expired.
- 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 ⏳ If the wait times out, or if the client doesn't use notifications, the MIDCOM client retrieves the status of the midcomRuleEntry with one or more SNMP GET operations.
- After receiving the midcomSolicitedRuleEvent notification, the 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 walking the midcomRuleTable 📋 For each row it sees, the SNMP agent should check the midcomRuleOperStatus to find out whether the row holds an established policy rule, or a rule that's still being built or has already been terminated 🕵️♀️
7.8. Policy Rule Status (PRS)
The SNMP agent can get all the status info and properties of a policy rule by reading the managed objects in the matching row of the midcomRuleTable 💅✨
7.9. Asynchronous Policy Rule Event (ARE) ✨
Okay so the ARE can get triggered in two ways, bestie 💅: either a policy rule's lifetime runs out, or its idle time expires. But wait, there's more 👀. The MIDCOM-MIB implementation can also terminate a policy rule whenever it wants, at any time 💀. No matter which trigger it is, there are two steps that are required for this transaction:
- The MIDCOM-MIB implementation sends a
midcomUnsolicitedRuleEventnotification containing a lifetime value of0to the MIDCOM client that owns the rule. - If the
midcomRuleStorageTimeobject in the matching row of themidcomRuleTablehas a value of0, the MIDCOM-MIB implementation removes that row from the table. Otherwise, it sets themidcomRuleLifetimeobject in that row to0and changes themidcomRuleOperStatusobject. If the event was triggered by the policy lifetime expiring,midcomRuleOperStatusis set totimedOut(9). Otherwise, it's set toterminated(11)🫶.
7.10. Group Lifetime Change (GLC) 🎀
This example walks through the steps a MIDCOM client may take to change the lifetime of a policy rule group. Setting the lifetime to 0 means terminating all the member policies of the group, so it's a whole group moment 🌸.
- The MIDCOM client issues a SET request to write the lifetime it wants into the
midcomGroupLifetimeobject in the matching row of themidcomGroupTable. - The MIDCOM client waits for a
midcomSolicitedGroupEventnotification about that row in themidcomGroupTable. The waiting gets timed out after a pre-selected maximum waiting time 🙈. If it times out while waiting for the notification, or if the client doesn't use notifications at all, the MIDCOM client checks the status of themidcomGroupEntrywith one or more SNMP GET operations instead. - After receiving the
midcomSolicitedRuleEventnotification, the MIDCOM client checks the lifetime value that the notification carries 🔥.
7.11. Group List (GL) 🦋
The SNMP agent can browse the list of policy rule groups by walking through the midcomGroupTable. For each row it sees, the SNMP agent should check the midcomGroupLifetime to figure out whether the group actually has established policies in it 👀.
7.12. Group Status (GS) 🧚
The SNMP agent can pull up all the member policies of a group by browsing the midcomRuleTable with the midcomGroupIndex of that group 💜. To get the remaining lifetime of the group, the SNMP agent reads the midcomGroupLifetime object in the matching row of the midcomGroupTable ⭐.
8. Usage Examples for Monitoring Objects 📊
This section has some examples of how a MIDCOM client can use the midcomResourceTable to link policy rules to the middlebox resources they use. There's one example for middleboxes that implement the NAT-MIB and another one for firewalls 🍓.
8.1. Monitoring NAT Resources 🌈
When a rule in the midcomRuleTable gets executed, it directly affects the middlebox resources. The midcomResourceTable tells you how the MIDCOM-MIB policy rules relate to the middlebox resources used to enforce them 💖.
A MIDCOM-MIB policy rule can create or modify up to two NAT bindings and up to two NAT sessions. Two NAT bindings are affected when a session is subject to twice-NAT. Two NAT bindings can also be affected when midcomRulePortRange is set to pair(2) in the policy rule. In most cases, where traditional NAT is in use, a single NAT binding is probably enough 🙌. Just note that the BindId is set to 0 if the middlebox is implementing symmetric NAT function 👀. Two NAT sessions are only created or modified when midcomRulePortRange is set to pair(2) in the policy rule 🎀.
When the middlebox also supports the NAT-MIB module, you can use the parameters from the midcomRuleTable and the midcomResourceTable for a given rule to index the matching BIND and NAT session resources affected in the NAT-MIB. These parameters are super useful for monitoring the effect on the NAT module, even when the NAT-MIB module isn't implemented at the middlebox ✨.
MIDCOM rules really matter for NAT resources because a MIDCOM rule can not only create BINDs and NAT sessions, but can also modify NAT objects that already exist 😭. For example, the FlowDirection and MaxIdleTime parameters in a MIDCOM rule directly affect the TranslationEntity and MaxIdleTime of the associated NAT bind object. Likewise, MaxIdleTime in a MIDCOM rule directly impacts the MaxIdleTime of the associated NAT session object. The lifetime parameter in the MIDCOM rule directly impacts the lifetime of all the affected 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, it may lead to one or more new firewall rules being created. Usually one firewall rule per MIDCOM-MIB policy rule is enough 👑. For each policy rule, a MIDCOM client can find the matching firewall filter rule by reading the midcomResourceEntry in the midcomResourceTable that corresponds to the midcomRuleEntry describing the rule. The identity of the firewall filter rule is stored in the midcomRscFirewallRuleId object. The value of midcomRscFirewallRuleId may correspond directly to any firewall filter rule number, or to an entry in a locally available firewall MIB module 🧚.
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 -- RFC 2578
TEXTUAL-CONVENTION, TruthValue,
StorageType, RowStatus
FROM SNMPv2-TC -- RFC 2579
MODULE-COMPLIANCE, OBJECT-GROUP,
NOTIFICATION-GROUP
FROM SNMPv2-CONF -- RFC 2580
SnmpAdminString
FROM SNMP-FRAMEWORK-MIB -- RFC 3411
InetAddressType, InetAddress,
InetPortNumber,
InetAddressPrefixLength
FROM INET-ADDRESS-MIB -- RFC 4001
InterfaceIndexOrZero
FROM IF-MIB -- RFC 2863
NatBindIdOrZero
FROM NAT-MIB; -- RFC 4008
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.
Kurfuersten-Anlage 36
69115 Heidelberg
Germany
Tel: +49 6221 4342-115
Email: quittek@nw.neclab.eu
Co-editor:
Martin Stiemerling
NEC Europe Ltd.
Kurfuersten-Anlage 36
69115 Heidelberg
Germany
Tel: +49 6221 4342-113
Email: stiemerling@nw.neclab.eu
Co-editor:
Pyda Srisuresh
Kazeon Systems, Inc.
1161 San Antonio Rd.
Mountain View, CA 94043
U.S.A.
Tel: +1 408 836-4773
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
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 (2008). This version
of this MIB module is part of RFC 5190; see the RFC
itself for full legal notices."
REVISION "200708091011Z" -- August 09, 2007
DESCRIPTION "Initial version, published as RFC 5190."
::= { mib-2 171 }
--
-- 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:
-- - objects modeling MIDCOM policy rules in the midcomRuleTable
-- - objects modeling MIDCOM policy rule groups in the
-- midcomGroupTable
--
-- 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 a 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, 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 }
okay so this is the row layout for the rule table 💖 every column of a MidcomRuleEntry is listed right here, in this exact order, so the table knows what's what 🎀
first up are the ownership and index columns 🔐 these two are the table index, so they're the bit that tells each row apart from the others 🦋
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 (VACM, RFC 3415)." ::= { 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 }
the owner object is basically the manager's ID badge, and it SHOULD be unique for each authenticated MIDCOM client 🕵️♀️✨ the index is the other half of the key and it has to be unique when you pair it with the owner and the group index 💅
midcomRuleAdminStatus OBJECT-TYPE SYNTAX INTEGER { reserve(1), enable(2), notSet(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object indicates the desired status of the policy rule. See the definition of midcomRuleOperStatus for a description of the values.
When 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
- 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 }
okay, the admin status is the "pls make this happen" knob 🙏 you can ask for reserve(1) or enable(2), but notSet(3) is off the menu for SET requests, and trying it gets you an 'inconsistentValue' error 🙈 the list of other columns that matter depends on which of the two you picked, so read those lists carefully bestie 📝
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.
- checkingRequest(3) indicates that midcomRuleAdminStatus has recently been set and that the MIDCOM-MIB implementation is currently checking the parameters of the request. This is a transient state. The value of this object will change to either incorrectRequest(4) or processingRequest(5) without any external interaction. A MIDCOM-MIB implementation MAY return this value while checking request parameters.
- incorrectRequest(4) indicates that checking a request resulted in detecting an incorrect value in one of the objects containing request parameters. The failure reason is indicated by the value of midcomRuleError.
- processingRequest(5) indicates that midcomRuleAdminStatus has recently been set and that the MIDCOM-MIB implementation is currently processing the request and trying to configure the middlebox accordingly. This is a transient state. The value of this object will change to either requestRejected(6), reserved(7), or enabled(8) without any external interaction. A MIDCOM-MIB implementation MAY return this value while processing a request.
- requestRejected(6) indicates that a request to establish
a policy rule specified by the entry was rejected. The reason for rejection is indicated by the value of midcomRuleError.
- reserved(7) indicates that the entry describes an established policy reserve rule. These values of MidcomRuleEntry are meaningful for a reserved policy rule:
- midcomRuleMaxIdleTime
- midcomRuleInterface
- midcomRuleTransportProtocol
- midcomRulePortRange
- midcomRuleInternalIpVersion
- midcomRuleExternalIpVersion
- midcomRuleInternalIpAddr
- midcomRuleInternalIpPrefixLength
- midcomRuleInternalPort
- midcomRuleOutsideIpAddr
- midcomRuleOutsidePort
- midcomRuleLifetime
- enabled(8) indicates that the entry describes an established policy enable rule. These values of MidcomRuleEntry are meaningful for an enabled policy rule:
- midcomRuleFlowDirection
- midcomRuleInterface
- midcomRuleMaxIdleTime
- midcomRuleTransportProtocol
- midcomRulePortRange
- midcomRuleInternalIpVersion
- midcomRuleExternalIpVersion
- midcomRuleInternalIpAddr
- midcomRuleInternalIpPrefixLength
- midcomRuleInternalPort
- midcomRuleExternalIpAddr
- midcomRuleExternalIpPrefixLength
- midcomRuleExternalPort
- midcomRuleInsideIpAddr
- midcomRuleInsidePort
- midcomRuleOutsideIpAddr
- midcomRuleOutsidePort
- midcomRuleLifetime
- timedOut(9) indicates that the lifetime of a previously established policy rule has expired and that the policy rule is terminated for this reason.
- terminatedOnRequest(10) indicates that a previously established policy rule was terminated by an SNMP manager setting the midcomRuleLifetime to 0 or setting midcomGroupLifetime to 0.
- terminated(11) indicates that a previously established policy rule was terminated by the MIDCOM-MIB implementation for a reason other than lifetime expiration or an explicit request from a MIDCOM client.
- genericError(12) indicates that the policy rule specified by the entry is not established due to an error condition not listed above.
The states timedOut(9), terminatedOnRequest(10), and terminated(11) are referred to as termination states.
The states incorrectRequest(4), requestRejected(6), and genericError(12) are referred to as error states."
The checkingRequest(3) and processingRequest(5)
states are transient states, which will lead to either
one of the error states or the reserved(7) state or the
enabled(8) state. MIDCOM-MIB implementations MAY return
these values when checking or processing requests."
DEFVAL { newEntry }
::= { midcomRuleEntry 5 }
midcomRuleStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"When retrieved, this object returns the storage
type of the policy rule. Writing to this object can
change the storage type of the particular row from
volatile(2) to nonVolatile(3) or vice versa.
Attempts to set this object to permanent will always
fail with an 'inconsistentValue' error. 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.
If midcomRuleStorageType has the value permanent(4),
then all objects in this row whose MAX-ACCESS value
is read-create must be read-only."
DEFVAL { volatile }
::= { midcomRuleEntry 6 }okay bestie, the storage type object is giving "where does my data live" energy 🧚💖 it tells you whether a rule is volatile(2) or nonVolatile(3), and there's a permanent(4) setting that's basically a locked-in look 🔒 setting it to permanent just throws an 'inconsistentValue' error 💀 (that part is SNMP specific, fr)
midcomRuleStorageTime OBJECT-TYPE
SYNTAX Unsigned32
UNITS "seconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The value of this object specifies how long this row
can exist in the midcomRuleTable after the
midcomRuleOperStatus switched to a termination state or
to an error state. This object returns the remaining
time that the row may exist before it is aged out.
After expiration or termination of the context, the value
of this object ticks backwards. The entry in the
midcomRuleTable is destroyed when the value reaches 0.
The value of this object may be set in order to increase
or reduce the remaining time that the row may exist.
Setting the value to 0 will destroy this entry as soon as
the midcomRuleOperStatus switched to a termination state
or to an error state.
Note that there is no guarantee that the row is stored as
long as this object indicates. At any time, the MIDCOM-
MIB implementation may decide to remove a row describing
a terminated policy rule before the storage time of the
corresponding row in the midcomRuleTable reaches the
value of 0. In this case, the information stored in this
row is not available anymore.
If object midcomRuleStorageType indicates that the policy
rule has the storage type permanent(4), then this object has
a constant value of 4294967295."
DEFVAL { 0 }
::= { midcomRuleEntry 7 }ngl this one is a countdown timer ⏳✨ it ticks backwards after the rule terminates or errors out, and when it hits 0 the entry is gone 👋 BUT there's no guarantee the row sticks around that long, so don't get too attached 🥺 the implementation can drop it early 💅 and yes, permanent(4) rules just sit at 4294967295 forever 🌸
midcomRuleError OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object contains a descriptive error message if
the transition into the operational status reserved(7)
or enabled(8) failed. Implementations must reset the
error message to a zero-length string when a new
attempt to change the policy rule status to reserved(7)
or enabled(8) is started.
RECOMMENDED values to be returned in particular cases
include
- 'lack of IP addresses'
- 'lack of port numbers'
- 'lack of resources'
- 'specified NAT interface does not exist'
- 'specified NAT interface does not support NAT'
- 'conflict with already existing policy rule'
- 'no internal IP wildcarding allowed'
- 'no external IP wildcarding allowed'
The semantics of these error messages and the corresponding
behavior of the MIDCOM-MIB implementation are specified
in sections 2.3.9 and 2.3.10 of RFC 3989."
REFERENCE
"RFC 3989, sections 2.3.9 and 2.3.10"
DEFVAL { ''H }
::= { midcomRuleEntry 8 }the error object is the drama queen of the table 🎭 it holds a descriptive message whenever the jump into reserved(7) or enabled(8) goes wrong, and the list of RECOMMENDED messages is right there 💅 the full semantics live in sections 2.3.9 and 2.3.10 of RFC 3989 📚 (cite it, babe, it's giving proper research energy 🤓)
midcomRuleInterface OBJECT-TYPE
SYNTAX InterfaceIndexOrZero
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object indicates the IP interface for which
enforcement of a policy rule is requested or performed,
respectively.
The interface is identified by its index in the ifTable
(see IF-MIB in RFC 2863). If the object has a value of 0,
then no particular interface is indicated.
This object is used as input to a request for establishing
a policy rule as well as for indicating the properties of
an established policy rule.
If object midcomRuleOperStatus of the same entry has the
value newEntry(1) or setting(2), then this object can be
written by a manager in order to request its preference
concerning the interface at which it requests NAT service.
The default value of 0 indicates that the manager does not
have a preferred interface or does not have sufficient
topology information for specifying one. Writing to this
object in any state other than newEntry(1) or setting(2)
will always fail with an 'inconsistentValue' error.
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.
If object midcomRuleOperStatus of the same entry has the
value reserved(7) or enabled(8), then this object indicates
the interface at which NAT service for this rule is
performed. If NAT service is not required for enforcing
the policy rule, then the value of this object is 0. Also,
if the MIDCOM-MIB implementation cannot indicate an
interface, because it does not have this information or
because NAT service is not offered at a particular single
interface, then the value of the object is 0.
Note that the index of a particular interface in the
ifTable may change after a re-initialization of the
middlebox, for example, after adding another interface to
it. In such a case, the value of this object may change,
but the interface referred to by the MIDCOM-MIB MUST still
be the same. If, after a re-initialization of the
middlebox, the interface referred to before
re-initialization cannot be uniquely mapped anymore to a
particular entry in the ifTable, then the value of object
midcomRuleOperStatus of the same entry MUST be changed to
terminated(11).
If object midcomRuleOperStatus of the same entry has a
value other than newEntry(1), setting(2), reserved(7), or
enabled(8), then the value of this object is irrelevant."
DEFVAL { 0 }
::= { midcomRuleEntry 9 }the interface object is all about where the rule lives 🦋 0 means "no particular interface," and the index comes from the ifTable (IF-MIB in RFC 2863) 🌈 there's a big MUST in here about the interface still being the same after a re-initialization, and if it can't be mapped anymore, the status flips to terminated(11) 😭 that's a whole plot twist, bestie
midcomRuleFlowDirection OBJECT-TYPE
SYNTAX INTEGER {
inbound(1),
outbound(2),
biDirectional(3)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This parameter specifies the direction of enabled
communication, either inbound(1), outbound(2), or
biDirectional(3).
The semantics of this object depends on the protocol
the rule relates to. If the rule is independent of
the transport protocol (midcomRuleTransportProtocol
has a value of 0) or if the transport protocol is UDP,
then the value of midcomRuleFlowDirection indicates
the direction of packets traversing the middlebox.
In this case, value inbound(1) indicates that packets
are traversing from outside to inside, value outbound(2)
indicates that packets are traversing from inside to
outside. For both values, inbound(1) and outbound(2)
packets can traverse the middlebox only unidirectional.
A bidirectional flow is indicated by value
biDirectional(3).
If the transport protocol is TCP, the packet flow is
always bidirectional, but the value of
midcomRuleFlowDirection indicates that:
- inbound(1): bidirectional TCP packet flow.
First packet, with TCP SYN flag set, must arrive
at an outside interface of the middlebox.
- outbound(2): bidirectional TCP packet flow.
First packet, with TCP SYN flag set, must arrive
at an inside interface of the middlebox.
- biDirectional(3): bidirectional TCP packet flow.
First packet, with TCP SYN flag set, may arrive
at an inside or an outside interface of the middlebox.
This object is used as input to a request for
establishing a policy enable rule as well as for
indicating the properties of an established policy rule.
If object midcomRuleOperStatus of the same entry has a
value of either newEntry(1), setting(2), or reserved(7),
then this object can be written by a manager in order to
specify a requested direction to be enabled by a policy
rule. Writing to this object in any state other than
newEntry(1), setting(2), or reserved(7) will always fail
with an 'inconsistentValue' error.
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.
If object midcomRuleOperStatus of the same entry has the
value enabled(8), then this object indicates the enabled
flow direction.
If object midcomRuleOperStatus of the same entry has a
value other than newEntry(1), setting(2), reserved(7), or
enabled(8), then the value of this object is irrelevant."
DEFVAL { outbound }
::= { midcomRuleEntry 10 }flow direction is where the vibes get very specific 🧭 for UDP (or anything transport-independent) it's about which way packets cross the box: inbound(1) is outside to inside, outbound(2) is inside to outside, and biDirectional(3) is the both-ways combo 🔁 TCP is always bidirectional, but the value tells you which side the first SYN has to show up on, and biDirectional(3) lets it come from either side 🫶
midcomRuleMaxIdleTime OBJECT-TYPE
SYNTAX Unsigned32
UNITS "seconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Maximum idle time of the policy rule in seconds.
If no packet to which the policy rule applies passes the
middlebox for the specified midcomRuleMaxIdleTime, then
the policy rule enters the termination state timedOut(9).
A value of 0 indicates that the policy does not require
an individual idle time and that instead, a default idle
time chosen by the middlebox is used.
A value of 4294967295 ( = 2^32 - 1 ) indicates that the
policy does not time out if it is idle.
This object is used as input to a request for
establishing a policy enable rule as well as for
indicating the properties of an established policy rule.If object midcomRuleOperStatus of the same entry has a value other than newEntry(1), setting(2), reserved(7), or enabled(8), then the value of this object is irrelevant." DEFVAL { 0 } ::= { midcomRuleEntry 11 }
midcomRuleTransportProtocol OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS read-create STATUS current DESCRIPTION "The transport protocol.
Valid values for midcomRuleTransportProtocol other than zero are defined at: http://www.iana.org/assignments/protocol-numbers
This object is used as input to a request for establishing a policy rule as well as for indicating the properties of an established policy rule.
If object midcomRuleOperStatus of the same entry has a value of either newEntry(1) or setting(2), then this object can be written by a manager in order to specify a requested transport protocol. If translation of an IP address only is requested, then this object must have the default value 0. Writing to this object in any state other than newEntry(1) or setting(2) will always fail with an 'inconsistentValue' error.
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.
If object midcomRuleOperStatus of the same entry has the value reserved(7) or enabled(8), then this object indicates which transport protocol is enforced by this policy rule. A value of 0 indicates a rule acting on IP addresses only.
If object midcomRuleOperStatus of the same entry has a value other than newEntry(1), setting(2), reserved(7), or enabled(8), then the value of this object is irrelevant."
DEFVAL { 0 } ::= { midcomRuleEntry 12 }
midcomRulePortRange OBJECT-TYPE SYNTAX INTEGER { single(1), pair(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The range of port numbers.
This object is used as input to a request for establishing a policy rule as well as for indicating the properties of an established policy rule. It is relevant to the operation of the MIDCOM-MIB implementation only if the value of object midcomTransportProtocol in the same entry has a value other than 0.
If object midcomRuleOperStatus of the same entry has the value newEntry(1) or setting(2), then this object can be written by a manager in order to specify the requested size of the port range. With single(1) just a single port number is requested, with pair(2) a consecutive pair of port numbers is requested with the lower number being even. Requesting a consecutive pair of port numbers may be used by RTP [RFC3550] and may even be required to support older RTP applications.
Writing to this object in any state other than newEntry(1), setting(2) or reserved(7) 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.
If object midcomRuleOperStatus of the same entry has a value of either reserved(7) or enabled(8), then this object will have the value that it had before the transition to this state.
If object midcomRuleOperStatus of the same entry has a value other than newEntry(1), setting(2), reserved(7), or enabled(8), then the value of this object is irrelevant." DEFVAL { single } ::= { midcomRuleEntry 13}
midcomRuleInternalIpVersion OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-create STATUS current DESCRIPTION "IP version of the internal address (A0) and the inside address (A1). Allowed values are ipv4(1), ipv6(2), ipv4z(3), and ipv6z(4).
This object is used as input to a request for establishing a policy rule as well as for indicating the properties of an established policy rule.
If object midcomRuleOperStatus of the same entry has the value newEntry(1) or setting(2), then this object can be written by a manager in order to specify the IP version required at the inside of the middlebox. Writing to this object in any state other than newEntry(1) or setting(2) will always fail with an 'inconsistentValue' error.
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.
If object midcomRuleOperStatus of the same entry has the value reserved(7) or enabled(8), then this object indicates the internal/inside IP version.
If object midcomRuleOperStatus of the same entry has a value other than newEntry(1), setting(2), reserved(7), or enabled(8), then the value of this object is irrelevant." DEFVAL { ipv4 } ::= { midcomRuleEntry 14 }
midcomRuleExternalIpVersion OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-create STATUS current DESCRIPTION "IP version of the external address (A3) and the outside address (A2). Allowed values are ipv4(1) and ipv6(2).
This object is used as input to a request for establishing a policy rule as well as for indicating the properties of an established policy rule.
If object midcomRuleOperStatus of the same entry has the value newEntry(1) or setting(2), then this object can be written by a manager in order to specify the IP version required at the outside of the middlebox. Writing to this object in any state other than newEntry(1) or setting(2) will always fail with an 'inconsistentValue' error. 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.
If object midcomRuleOperStatus of the same entry has the value reserved(7) or enabled(8), then this object indicates the external/outside IP version.
If object midcomRuleOperStatus of the same entry has a value other than newEntry(1), setting(2), reserved(7) or enabled(8), then the value of this object is irrelevant." DEFVAL { ipv4 } ::= { midcomRuleEntry 15 }
midcomRuleInternalIpAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The internal IP address (A0).
This object is used as input to a request for establishing a policy rule as well as for indicating the properties of an established policy rule.
If object midcomRuleOperStatus of the same entry has the value newEntry(1) or setting(2), then this object can be written by a manager in order to specify the internal IP address for which a reserve policy rule or a enable policy rule is requested to be established. Writing to this object in any state other than newEntry(1) or setting(2) will always fail with an 'inconsistentValue' error. 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.
If object midcomRuleOperStatus of the same entry has the value reserved(7) or enabled(8), then this object will have the value which it had before the transition to this state.
If object midcomRuleOperStatus of the same entry has a value other than newEntry(1), setting(2), reserved(7) or enabled(8), then the value of this object is irrelevant." ::= { midcomRuleEntry 16 }
midcomRuleInternalIpPrefixLength OBJECT-TYPE SYNTAX InetAddressPrefixLength MAX-ACCESS read-create STATUS current DESCRIPTION "The prefix length of the internal IP address used for wildcarding. A value of 0 indicates a full wildcard; in this case, the value of midcomRuleInternalIpAddr is irrelevant. If midcomRuleInternalIpVersion has a value of ipv4(1), then a value > 31 indicates no wildcarding at all. If midcomRuleInternalIpVersion has a value of ipv4(2), then a value > 127 indicates no wildcarding at all. A MIDCOM-MIB implementation that does not support IP address wildcarding MUST implement this object as read-only with a value of 128. A MIDCOM that does not support wildcarding based on prefix length MAY restrict allowed values for this object to 0 and 128.
This object is used as input to a request for establishing a policy rule as well as for indicating the properties of an established policy rule.
If object midcomRuleOperStatus of the same entry has the value newEntry(1) or setting(2), then this object can be written by a manager in order to specify the prefix length of the internal IP address for which a reserve policy rule or an enable policy rule is requested to be established. Writing to this object in any state other than newEntry(1) or setting(2) will always fail with an 'inconsistentValue' error.
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.
Okay bestie, the rule entry keeps going with more objects: the wildcarding settings, the internal and external ports, the inside and outside addresses, and the lifetime rules. ✨🎀
If object midcomRuleOperStatus of the same entry has the
value reserved(7) or enabled(8), then this object will
have the value which it had before the transition to this
state.
If object midcomRuleOperStatus of the same entry has a
value other than newEntry(1), setting(2), reserved(7), or
enabled(8), then the value of this object is irrelevant."
DEFVAL { 128 }
::= { midcomRuleEntry 17 }
midcomRuleInternalPort OBJECT-TYPE
SYNTAX InetPortNumber
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The internal port number. A value of 0 is a wildcard.
This object is used as input to a request for establishing
a policy rule as well as for indicating the properties of
an established policy rule. It is relevant to the
operation of the MIDCOM-MIB implementation only if the
value of object midcomTransportProtocol in the same entry
has a value other than 0.
If object midcomRuleOperStatus of the same entry has the
value newEntry(1) or setting(2), then this object can be
written by a manager in order to specify the internal port
number for which a reserve policy rule or an enable policy
rule is requested to be established. Writing to this
object in any state other than newEntry(1) or setting(2)
will always fail with an 'inconsistentValue' error.
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.
If object midcomRuleOperStatus of the same entry has the
value reserved(7) or enabled(8), then this object will
have the value that it had before the transition to this
state.
If object midcomRuleOperStatus of the same entry has a
value other than newEntry(1), setting(2), reserved(7), or
enabled(8), then the value of this object is irrelevant."
DEFVAL { 0 }
::= { midcomRuleEntry 18 }
midcomRuleExternalIpAddr OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The external IP address (A3).
This object is used as input to a request for establishing
a policy rule as well as for indicating the properties of
an established policy rule.
If object midcomRuleOperStatus of the same entry has the
value newEntry(1), setting(2), or reserved(7), then this
object can be written by a manager in order to specify the
external IP address for which an enable policy rule is
requested to be established. Writing to this object in
any state other than newEntry(1), setting(2), or reserved(7)
will always fail with an 'inconsistentValue' error.
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.
If object midcomRuleOperStatus of the same entry has the
value enabled(8), then this object will have the value
that it had before the transition to this state.
If object midcomRuleOperStatus of the same entry has a
value other than newEntry(1), setting(2), reserved(7), or
enabled(8), then the value of this object is irrelevant."
::= { midcomRuleEntry 19 }
midcomRuleExternalIpPrefixLength OBJECT-TYPE
SYNTAX InetAddressPrefixLength
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The prefix length of the external IP address used for
wildcarding. A value of 0 indicates a full wildcard;
in this case, the value of midcomRuleExternalIpAddr is
irrelevant. If midcomRuleExternalIpVersion has a value
of ipv4(1), then a value > 31 indicates no wildcarding
at all. If midcomRuleExternalIpVersion has a value
of ipv4(2), then a value > 127 indicates no wildcarding
at all. A MIDCOM-MIB implementation that does not
support IP address wildcarding MUST implement this object
as read-only with a value of 128. A MIDCOM that does
not support wildcarding based on prefix length MAY
restrict allowed values for this object to 0 and 128.
This object is used as input to a request for establishing
a policy rule as well as for indicating the properties of
an established policy rule.
If object midcomRuleOperStatus of the same entry has the
value newEntry(1), setting(2), or reserved(7), then this
object can be written by a manager in order to specify the
prefix length of the external IP address for which an
enable policy rule is requested to be established.
Writing to this object in any state other than
newEntry(1), setting(2), or reserved(7) will always fail
with an 'inconsistentValue' error.
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.
If object midcomRuleOperStatus of the same entry has the
value enabled(8), then this object will have the value
that it had before the transition to this state.
If object midcomRuleOperStatus of the same entry has a
value other than newEntry(1), setting(2), reserved(7), or
enabled(8), then the value of this object is irrelevant."
DEFVAL { 128 }
::= { midcomRuleEntry 20 }
midcomRuleExternalPort OBJECT-TYPE
SYNTAX InetPortNumber
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The external port number. A value of 0 is a wildcard.
This object is used as input to a request for establishing
a policy rule as well as for indicating the properties of
an established policy rule. It is relevant to the
operation of the MIDCOM-MIB implementation only if the
value of object midcomTransportProtocol in the same entry
has a value other than 0.
If object midcomRuleOperStatus of the same entry has the
value newEntry(1), setting(2) or reserved(7), then this
object can be written by a manager in order to specify the
external port number for which an enable policy rule is
requested to be established. Writing to this object in
any state other than newEntry(1), setting(2) or reserved(7)
will always fail with an 'inconsistentValue' error.
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.
If object midcomRuleOperStatus of the same entry has the
value enabled(8), then this object will have the value
which it had before the transition to this state.
If object midcomRuleOperStatus of the same entry has a
value other than newEntry(1), setting(2), reserved(7) or
enabled(8), then the value of this object is irrelevant."
DEFVAL { 0 }
::= { midcomRuleEntry 21 }
midcomRuleInsideIpAddr OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The inside IP address at the middlebox (A1).
The value of this object is relevant only if
object midcomRuleOperStatus of the same entry has
a value of either reserved(7) or enabled(8)."
::= { midcomRuleEntry 22 }
midcomRuleInsidePort OBJECT-TYPE
SYNTAX InetPortNumber
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The inside port number at the middlebox.
A value of 0 is a wildcard.
The value of this object is relevant only if
object midcomRuleOperStatus of the same entry has
a value of either reserved(7) or enabled(8)."
::= { midcomRuleEntry 23 }
midcomRuleOutsideIpAddr OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The outside IP address at the middlebox (A2).
The value of this object is relevant only if
object midcomRuleOperStatus of the same entry has
a value of either reserved(7) or enabled(8)."
::= { midcomRuleEntry 24 }
midcomRuleOutsidePort OBJECT-TYPE
SYNTAX InetPortNumber
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The outside port number at the middlebox.
A value of 0 is a wildcard.
The value of this object is relevant only if
object midcomRuleOperStatus of the same entry has
a value of either reserved(7) or enabled(8)."
::= { midcomRuleEntry 25 }
midcomRuleLifetime OBJECT-TYPE
SYNTAX Unsigned32
UNITS "seconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The remaining lifetime in seconds of this policy rule.
Lifetime of a policy rule starts when object
midcomRuleOperStatus in the same entry enters either
state reserved(7) or state enabled(8).
This object is used as input to a request for establishing
a policy rule as well as for indicating the properties of
an established policy rule.
If object midcomRuleOperStatus of the same entry has a
value of either newEntry(1) or setting(2), then this
object can be written by a manager in order to specify
the requested lifetime of a policy rule to be established.
If object midcomRuleOperStatus of the same entry has a
value of either reserved(7) or enabled(8), then this
object indicates the (continuously decreasing) remaining
lifetime of the established policy rule. Note that when
entering state reserved(7) or enabled(8), the MIDCOM-MIB
implementation can choose a lifetime shorter than the one
requested.
Unlike other parameters of the policy rule, this parameter
can still be written in state reserved(7) and enabled(8).
Writing to this object is processed by the MIDCOM-MIB
implementation by choosing a lifetime value that is
greater than 0 and less than or equal to the minimum of
the requested value and the value specified by object
midcomConfigMaxLifetime:
0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum)
where:
- lt_granted is the actually granted lifetime by the
MIDCOM-MIB implementation
- lt_requested is the requested lifetime of the MIDCOM
client
- lt_maximum is the value of object
midcomConfigMaxLifetimeokay bestie, the MIB is still going and the rule lifetime stuff is wrapping up 💖 here's the rest of that description plus the RowStatus object 🎀
SNMP SET requests to this object may be rejected or the
value of the object after an accepted SET operation may be
less than the value that was contained in the SNMP SET
request.
Successfully writing a value of 0 terminates the policy
rule. Note that after a policy rule is terminated, still
the entry will exist as long as indicated by the value of
midcomRuleStorageTime.
Writing to this object in any state other than
newEntry(1), setting(2), reserved(7), or enabled(7)
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.
If object midcomRuleOperStatus of the same entry has a
value other than newEntry(1), setting(2), reserved(7), or
enabled(8), then the value of this object is irrelevant."
DEFVAL { 180 }
::= { midcomRuleEntry 26 }
midcomRuleRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"A control that allows entries to be added and removed from
this table.
Entries can also be removed from this table by setting
objects midcomRuleLifetime and midcomRuleStorageTime of
an entry to 0.
Attempts to set a row notInService(2) where the value
of the midcomRuleStorageType object is permanent(4) or
readOnly(5) will result in an 'notWritable' 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.
The value of this object has no effect on whether other
objects in this conceptual row can be modified."
::= { midcomRuleEntry 27 }next up is the policy rule group subtree, where groups basically tag along with the rules that belong to them 🧚
--
-- Policy rule group subtree
--
-- The midcomGroupTable lists all current policy rule groups.
--
midcomGroupTable OBJECT-TYPE
SYNTAX SEQUENCE OF MidcomGroupEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table lists all current policy rule groups.
Entries in this table are created or removed
implicitly when entries in the midcomRuleTable are
created or removed, respectively. A group entry
in this table only exists as long as there are
member rules of this group in the midcomRuleTable.
The table serves for listing the existing groups and
their remaining lifetimes and for changing lifetimes
of groups and implicitly of all group members.
Groups and all their member policy rules can only be
deleted by deleting all member policies in the
midcomRuleTable.
Setting midcomGroupLifetime will result in setting
the lifetime of all policy members to the same value."
::= { midcomTransaction 4 }
midcomGroupEntry OBJECT-TYPE
SYNTAX MidcomGroupEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry describing properties of a particular
MIDCOM policy rule group."
INDEX { midcomRuleOwner, midcomGroupIndex }
::= { midcomGroupTable 1 }
MidcomGroupEntry ::= SEQUENCE {
midcomGroupIndex Unsigned32,
midcomGroupLifetime Unsigned32
}
midcomGroupIndex OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The index of this group for the midcomRuleOwner.
A group is identified by the combination of
midcomRuleOwner and midcomGroupIndex.
The value of this index must be unique per
midcomRuleOwner."
::= { midcomGroupEntry 2 }
midcomGroupLifetime OBJECT-TYPE
SYNTAX Unsigned32
UNITS "seconds"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"When retrieved, this object delivers the maximum
lifetime in seconds of all member rules of this group,
i.e., of all rows in the midcomRuleTable that have the
same values for midcomRuleOwner and midcomGroupIndex.
Successfully writing to this object modifies the
lifetime of all member policies. Successfully
writing a value of 0 terminates all member policies
and implicitly deletes the group as soon as all member
entries are removed from the midcomRuleTable.
Note that after a group's lifetime is expired or is
set to 0, still the corresponding entry in the
midcomGroupTable will exist as long as terminated
member policy rules are stored as entries in the
midcomRuleTable.
Writing to this object is processed by the MIDCOM-MIB
implementation by choosing a lifetime value that is
greater than 0 and less than or equal to the minimum of
the requested value and the value specified by object
midcomConfigMaxLifetime:
0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum)
where:
- lt_granted is the actually granted lifetime by the
MIDCOM-MIB implementation
- lt_requested is the requested lifetime of the MIDCOM
client
- lt_maximum is the value of object
midcomConfigMaxLifetime
SNMP SET requests to this object may be rejected or the
value of the object after an accepted SET operation may be
less than the value that was contained in the SNMP SET
request."
::= { midcomGroupEntry 3 }now we get to the configuration objects, which are the settings a middlebox reports about itself 🌸 the config section gets a heads up that clients usually shouldn't be writing to these, so access needs to be locked down tighter than the transaction stuff 🔒
--
-- Configuration Objects
--
-- Configuration objects that can be used for retrieving
-- middlebox capability information (mandatory) and for
-- setting parameters of the implementation of transaction
-- objects (optional).
--
-- 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.
--
--
-- Capabilities subtree
--
-- This subtree contains objects to which MIDCOM clients should
-- have read access.
--
midcomConfigMaxLifetime OBJECT-TYPE
SYNTAX Unsigned32
UNITS "seconds"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"When retrieved, this object returns the maximum lifetime,
in seconds, that this middlebox allows policy rules to
have."
::= { midcomConfig 1 }
midcomConfigPersistentRules OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"When retrieved, this object returns true(1) if the
MIDCOM-MIB implementation can store policy rules
persistently. Otherwise, it returns false(2).
A value of true(1) indicates that there may be
entries in the midcomRuleTable with object
midcomRuleStorageType set to value nonVolatile(3)."
::= { midcomConfig 2 }
midcomConfigIfTable OBJECT-TYPE
SYNTAX SEQUENCE OF MidcomConfigIfEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table indicates capabilities of the MIDCOM-MIB
implementation per IP interface.
The table is indexed by the object midcomConfigIfIndex.
For indexing a single interface, this object contains
the value of the ifIndex object that is associated
with the interface. If an entry with
midcomConfigIfIndex = 0 occurs, then bits set in
objects of this entry apply to all interfaces for which
there is no entry in this table with the interface's
index."
::= { midcomConfig 3 }
midcomConfigIfEntry OBJECT-TYPE
SYNTAX MidcomConfigIfEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry describing the capabilities of a middlebox
with respect to the indexed IP interface."
INDEX { midcomConfigIfIndex }
::= { midcomConfigIfTable 1 }
MidcomConfigIfEntry ::= SEQUENCE {
midcomConfigIfIndex InterfaceIndexOrZero,
midcomConfigIfBits BITS,
midcomConfigIfEnabled TruthValue
}
midcomConfigIfIndex OBJECT-TYPE
SYNTAX InterfaceIndexOrZero
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The index of an entry in the midcomConfigIfTable.
For values different from zero, this object
identifies an IP interface by containing the same
value as the ifIndex object associated with the
interface.
Note that the index of a particular interface in the
ifTable may change after a re-initialization of the
middlebox, for example, after adding another interface to
it. In such a case, the value of this object may change,
but the interface referred to by the MIDCOM-MIB MUST still
be the same. If, after a re-initialization of the
middlebox, the interface referred to before
re-initialization cannot be uniquely mapped anymore to a
particular entry in the ifTable, then the value of object
midcomConfigIfEnabled of the same entry MUST be changed to
false(2).
If the object has a value of 0, then values
specified by further objects of the same entry
apply to all interfaces for which there is no
explicit entry in the midcomConfigIfTable."
::= { midcomConfigIfEntry 1 }
midcomConfigIfBits OBJECT-TYPE
SYNTAX BITS {
ipv4(0),
ipv6(1),
addressWildcards(2),
portWildcards(3),
firewall(4),
nat(5),
portTranslation(6),
protocolTranslation(7),
twiceNat(8),
inside(9)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"When retrieved, this object returns a set of bits
indicating the capabilities (or configuration) of
the middlebox with respect to the referenced IP interface.
If the index equals 0, then all set bits apply to all
interfaces.
If the ipv4(0) bit is set, then the middlebox supports
IPv4 at the indexed IP interface.
If the ipv6(1) bit is set, then the middlebox supports
IPv6 at the indexed IP interface.
If the addressWildcards(2) bit is set, then the
middlebox supports IP address wildcarding at the indexed
IP interface.
If the portWildcards(3) bit is set, then the
middlebox supports port wildcarding at the indexed
IP interface.
If the firewall(4) bit is set, then the middlebox offers
firewall functionality at the indexed interface.Okay bestie, we're still deep in the MIB, so picking up right where the nat(5) bit description leaves off 💅✨
If the nat(5) bit is set, then the middlebox offers
network address translation service at the indexed
interface.
If the portTranslation(6) bit is set, then the middlebox
offers port translation service at the indexed interface.
This bit is only relevant if nat(5) is set.
If the protocolTranslation(7) bit is set, then the
middlebox offers protocol translation service between
IPv4 and IPv6 at the indexed interface. This bit is only
relevant if nat(5) is set.
If the twiceNat(8) bit is set, then the middlebox offers
twice network address translation service at the indexed
interface. This bit is only relevant if nat(5) is set.
If the inside(9) bit is set, then the indexed interface is
an inside interface with respect to NAT functionality.
Otherwise, it is an outside interface. This bit is only
relevant if nat(5) is set. An SNMP agent supporting both
the MIDCOM-MIB module and the NAT-MIB module SHOULD ensure
that the value of this object is consistent with the values
of corresponding objects in the NAT-MIB module."
::= { midcomConfigIfEntry 2 }
midcomConfigIfEnabled OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The value of this object indicates the availability of
the middlebox service described by midcomConfigIfBits
at the indexed IP interface.
By writing to this object, the MIDCOM support for the
entire IP interface can be switched on or off. Setting
this object to false(2) immediately stops middlebox
support at the indexed IP interface. This implies that
all policy rules that use NAT or firewall resources at
the indexed IP interface are terminated immediately.
In this case, the MIDCOM agent MUST send
midcomUnsolicitedRuleEvent to all MIDCOM clients that
have access to one of the terminated rules."
DEFVAL { true }
::= { midcomConfigIfEntry 3 }
--
-- Firewall subtree
--
-- This subtree contains the firewall configuration table
--
midcomConfigFirewallTable OBJECT-TYPE
SYNTAX SEQUENCE OF MidcomConfigFirewallEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table lists the firewall configuration per IP interface.
It can be used for configuring how policy rules created by
MIDCOM clients are realized as firewall rules of a firewall
implementation. Particularly, the priority used for MIDCOM
policy rules can be configured. For a single firewall
implementation at a particular IP interface, all MIDCOM
policy rules are realized as firewall rules with the same
priority. Also, a firewall rule group name can be
configured.
The table is indexed by the object midcomConfigFirewallIndex.
For indexing a single interface, this object contains the
value of the ifIndex object that is associated with the
interface. If an entry with midcomConfigFirewallIndex = 0
occurs, then bits set in objects of this entry apply to all
interfaces for which there is no entry in this table for the
interface's index."
::= { midcomConfig 4 }
midcomConfigFirewallEntry OBJECT-TYPE
SYNTAX MidcomConfigFirewallEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry describing a particular set of
firewall resources."
INDEX { midcomConfigFirewallIndex }
::= { midcomConfigFirewallTable 1 }
MidcomConfigFirewallEntry ::= SEQUENCE {
midcomConfigFirewallIndex InterfaceIndexOrZero,
midcomConfigFirewallGroupId SnmpAdminString,
midcomConfigFirewallPriority Unsigned32
}
midcomConfigFirewallIndex OBJECT-TYPE
SYNTAX InterfaceIndexOrZero
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The index of an entry in the midcomConfigFirewallTable.
For values different from 0, this object identifies an
IP interface by containing the same value as the ifIndex
object associated with the interface.
Note that the index of a particular interface in the
ifTable may change after a re-initialization of the
middlebox, for example, after adding another interface to
it. In such a case, the value of this object may change,
but the interface referred to by the MIDCOM-MIB MUST still
be the same. If, after a re-initialization of the
middlebox, the interface referred to before
re-initialization cannot be uniquely mapped anymore to a
particular entry in the ifTable, then the entry in the
midcomConfigFirewallTable MUST be deleted.
If the object has a value of 0, then values specified by
further objects of the same entry apply to all interfaces
for which there is no explicit entry in the
midcomConfigFirewallTable."
::= { midcomConfigFirewallEntry 1 }
midcomConfigFirewallGroupId OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The firewall rule group to which all firewall rules are
assigned that the MIDCOM server creates for the interface
indicated by object midcomConfigFirewallIndex. If the
value of object midcomConfigFirewallIndex is 0, then all
firewall rules of the MIDCOM server that are created for
interfaces with no specific entry in the
midcomConfigFirewallTable are assigned to the firewall
rule group indicated by the value of this object."
::= { midcomConfigFirewallEntry 2 }
midcomConfigFirewallPriority OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The priority assigned to all firewall rules that the
MIDCOM server creates for the interface indicated by
object midcomConfigFirewallIndex. If the value of object
midcomConfigFirewallIndex is 0, then this priority is
assigned to all firewall rules of the MIDCOM server that
are created for interfaces for which there is no specific
entry in the midcomConfigFirewallTable."
::= { midcomConfigFirewallEntry 3 }Next up is the monitoring objects part of the module, where the resource tables live. This bit is giving "organised" energy with all the subtree labels 🧚🌸
--
-- Monitoring Objects
--
-- Monitoring objects are structured into two groups,
-- the midcomResourceGroup providing information about used
-- resources and the midcomStatisticsGroup providing information
-- about MIDCOM transaction statistics.
--
-- Resources subtree
--
-- The MIDCOM resources subtree contains a set of managed
-- objects describing the currently used resources of NAT
-- and firewall implementations.
--
--
-- Textual conventions for objects of the resource subtree
--
MidcomNatBindMode ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"An indicator of the kind of NAT resources used by a policy
rule. This definition corresponds to the definition of
NatBindMode in the NAT-MIB (RFC 4008). Value none(3) can
be used to indicate that the policy rule does not use
any NAT binding.
"
SYNTAX INTEGER {
addressBind(1),
addressPortBind(2),
none(3)
}
MidcomNatSessionIdOrZero ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"A unique ID that is assigned to each NAT session by
a NAT implementation. This definition corresponds to
the definition of NatSessionId in the NAT-MIB (RFC 4008).
Value 0 can be used to indicate that the policy rule does
not use any NAT binding."
SYNTAX Unsigned32
--
-- The MIDCOM resource table
--
midcomResourceTable OBJECT-TYPE
SYNTAX SEQUENCE OF MidcomResourceEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table lists all used middlebox resources per
MIDCOM policy rule.
The midcomResourceTable augments the
midcomRuleTable."
::= { midcomMonitoring 1 }
midcomResourceEntry OBJECT-TYPE
SYNTAX MidcomResourceEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry describing a particular set of middlebox
resources."
AUGMENTS { midcomRuleEntry }
::= { midcomResourceTable 1 }
MidcomResourceEntry ::= SEQUENCE {
midcomRscNatInternalAddrBindMode MidcomNatBindMode,
midcomRscNatInternalAddrBindId NatBindIdOrZero,
midcomRscNatInsideAddrBindMode MidcomNatBindMode,
midcomRscNatInsideAddrBindId NatBindIdOrZero,
midcomRscNatSessionId1 MidcomNatSessionIdOrZero,
midcomRscNatSessionId2 MidcomNatSessionIdOrZero,
midcomRscFirewallRuleId Unsigned32
}
midcomRscNatInternalAddrBindMode OBJECT-TYPE
SYNTAX MidcomNatBindMode
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"An indication of whether this policy rule uses an address
NAT bind or an address-port NAT bind for binding the
internal address.
If the MIDCOM-MIB module is operated together with
the NAT-MIB module (RFC 4008) then object
midcomRscNatInternalAddrBindMode contains the same
value as the corresponding object
natSessionPrivateSrcEPBindMode of the NAT-MIB module."
::= { midcomResourceEntry 4 }
midcomRscNatInternalAddrBindId OBJECT-TYPE
SYNTAX NatBindIdOrZero
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object references to the allocated internal NAT
bind that is used by this policy rule. A NAT bind
describes the mapping of internal addresses to
outside addresses. MIDCOM-MIB implementations can
read this object to learn the corresponding NAT bind
resource for this particular policy rule.
If the MIDCOM-MIB module is operated together with
the NAT-MIB module (RFC 4008) then object
midcomRscNatInternalAddrBindId contains the same
value as the corresponding object
natSessionPrivateSrcEPBindId of the NAT-MIB module."
::= { midcomResourceEntry 5 }
midcomRscNatInsideAddrBindMode OBJECT-TYPE
SYNTAX MidcomNatBindMode
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"An indication of whether this policy rule uses an address
NAT bind or an address-port NAT bind for binding the
external address.
If the MIDCOM-MIB module is operated together with
the NAT-MIB module (RFC 4008), then object
midcomRscNatInsideAddrBindMode contains the same
value as the corresponding object
natSessionPrivateDstEPBindMode of the NAT-MIB module."
::= { midcomResourceEntry 6 }okay so this bit is all about the resource pointers 🧚 each policy rule can point at its NAT bind, its NAT sessions, and its firewall rule, and these objects let you peek at them 👀
midcomRscNatInsideAddrBindId OBJECT-TYPE
SYNTAX NatBindIdOrZero
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object refers to the allocated external NAT
bind that is used by this policy rule. A NAT bind
describes the mapping of external addresses to
inside addresses. MIDCOM-MIB implementations can
read this object to learn the corresponding NAT bind
resource for this particular policy rule.
If the MIDCOM-MIB module is operated together with the
NAT-MIB module (RFC 4008), then object
midcomRscNatInsideAddrBindId contains the same
value as the corresponding object
natSessionPrivateDstEPBindId of the NAT-MIB module."
::= { midcomResourceEntry 7 }the NAT bind one is giving "mapping table" energy 🗺️ it's how external addresses get matched up with inside addresses. and if you're running MIDCOM-MIB next to NAT-MIB [RFC4008] (💅 the citation stays as is), the value has to match the natSessionPrivateDstEPBindId over on the NAT-MIB side. no drama, just consistency ✨
midcomRscNatSessionId1 OBJECT-TYPE
SYNTAX MidcomNatSessionIdOrZero
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object refers to the first allocated NAT session for
this policy rule. MIDCOM-MIB implementations can read this
object to learn whether or not a NAT session for a
particular policy rule is used. A value of 0 means that no
NAT session is allocated for this policy rule. A value
other than 0 refers to the NAT session."
::= { midcomResourceEntry 8 }
midcomRscNatSessionId2 OBJECT-TYPE
SYNTAX MidcomNatSessionIdOrZero
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object refers to the second allocated NAT session for
this policy rule. MIDCOM-MIB implementations can read this
object to learn whether or not a NAT session for a
particular policy rule is used. A value of 0 means that no
NAT session is allocated for this policy rule. A value
other than 0 refers to the NAT session."
::= { midcomResourceEntry 9 }so these two are the NAT session slots 🎀 session one and session two. a 0 means that slot is empty (no session allocated for this rule), and anything non-zero is pointing at a real session. super simple, very clean 🫶
midcomRscFirewallRuleId OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object refers to the allocated firewall
rule in the firewall engine for this policy rule.
MIDCOM-MIB implementations can read this value to
learn whether a firewall rule for this particular
policy rule is used or not. A value of 0 means that
no firewall rule is allocated for this policy rule.
A value other than 0 refers to the firewall rule
number within the firewall engine."
::= { midcomResourceEntry 10 }and this one is the firewall rule ID 🔥 same deal as the sessions. 0 means nothing got allocated, and any other number is the rule number inside the firewall engine.
okay now we're entering the statistics subtree 📊 it's basically a scrapbook of counters that show how the transaction objects have been used. every single one of these is read-only, so the MIB is just telling you what happened, never letting you change it 💜
--
-- Statistics subtree
--
-- The MIDCOM statistics subtree contains a set of managed
-- objects providing statistics about the usage of transaction
-- objects.
--
midcomStatistics OBJECT IDENTIFIER ::= { midcomMonitoring 2 }
midcomCurrentOwners OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of different values for midcomRuleOwner
for all current entries in the midcomRuleTable."
::= { midcomStatistics 1 }
midcomTotalRejectedRuleEntries OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of failed attempts to create an entry
in the midcomRuleTable."
::= { midcomStatistics 2 }
midcomCurrentRulesIncomplete OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The current number of policy rules that are incomplete.
Policy rules are loaded via row entries in the
midcomRuleTable. This object counts policy rules that are
loaded but not fully specified, i.e., they are in state
newEntry(1) or setting(2)."
::= { midcomStatistics 3 }
midcomTotalIncorrectReserveRules OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of policy reserve rules that failed
parameter check and entered state incorrectRequest(4)."
::= { midcomStatistics 4 }
midcomTotalRejectedReserveRules OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of policy reserve rules that failed
while being processed and entered state requestRejected(6)."
::= { midcomStatistics 5 }
midcomCurrentActiveReserveRules OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of currently active policy reserve rules."
::= { midcomStatistics 6 }
midcomTotalExpiredReserveRules OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of expired policy reserve rules
(entered termination state timedOut(9))."
::= { midcomStatistics 7 }
midcomTotalTerminatedOnRqReserveRules OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of policy reserve rules that were
terminated on request (entered termination state
terminatedOnRequest(10))."
::= { midcomStatistics 8 }
midcomTotalTerminatedReserveRules OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of policy reserve rules that were
terminated, but not on request (entered termination state
terminated(11))."
::= { midcomStatistics 9 }
midcomTotalIncorrectEnableRules OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of policy enable rules that failed
parameter check and entered state incorrectRequest(4)."
::= { midcomStatistics 10 }
midcomTotalRejectedEnableRules OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of policy enable rules that failed
while being processed and entered state requestRejected(6)."
::= { midcomStatistics 11 }
midcomCurrentActiveEnableRules OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of currently active policy enable rules."
::= { midcomStatistics 12 }
midcomTotalExpiredEnableRules OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of expired policy enable rules
(entered termination state timedOut(9))."
::= { midcomStatistics 13 }
midcomTotalTerminatedOnRqEnableRules OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of policy enable rules that were
terminated on request (entered termination state
terminatedOnRequest(10))."
::= { midcomStatistics 14 }
midcomTotalTerminatedEnableRules OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of policy enable rules that were
terminated, but not on request (entered termination state
terminated(11))."
::= { midcomStatistics 15 }so the counters split into two families, reserve rules and enable rules 🧁 each one tracks how many got rejected, how many are active right now, how many expired, and how many got terminated. the Counter32 ones only go up, and the Gauge32 ones tell you what's live at this exact moment 💅
time for notifications 🔔 these are the events the agent fires off when something changes. the ones labelled "unsolicited" happen on their own, and the "solicited" ones come after a MIDCOM client asked for the change.
--
-- Notifications.
--
midcomUnsolicitedRuleEvent NOTIFICATION-TYPE
OBJECTS { midcomRuleOperStatus, midcomRuleLifetime }
STATUS current
DESCRIPTION
"This notification is generated whenever the value of
midcomRuleOperStatus enters any error state or any
termination state without an explicit trigger by a
MIDCOM client."
::= { midcomNotifications 1 }
midcomSolicitedRuleEvent NOTIFICATION-TYPE
OBJECTS { midcomRuleOperStatus, midcomRuleLifetime }
STATUS current
DESCRIPTION
"This notification is generated whenever the value
of midcomRuleOperStatus enters one of the states
{reserved, enabled, any error state, any termination state}
as a result of a MIDCOM agent writing successfully to
object midcomRuleAdminStatus.
In addition, it is generated when the lifetime of
a rule was changed by successfully writing to object
midcomRuleLifetime."
::= { midcomNotifications 2 }
midcomSolicitedGroupEvent NOTIFICATION-TYPE
OBJECTS { midcomGroupLifetime }
STATUS current
DESCRIPTION
"This notification is generated for indicating that the
lifetime of all member rules of the group was changed by
successfully writing to object midcomGroupLifetime.
Note that this notification is only sent if the lifetime
of a group was changed by successfully writing to object
midcomGroupLifetime. No notification is sent
- if a group's lifetime is changed by writing to object
midcomRuleLifetime of any of its member policies,
- if a group's lifetime expires (in this case,
notifications are sent for all member policies), or
- if the group is terminated by terminating the last
of its member policies without writing to object
midcomGroupLifetime."
::= { midcomNotifications 3 }the group one is a bit of a plot twist 🎭 it only fires when the group's lifetime gets changed directly on midcomGroupLifetime. changing the lifetime through a member's midcomRuleLifetime doesn't count, a group lifetime running out doesn't count, and a group wrapping up because its last member got terminated doesn't count either. so read the fine print, bestie 🫶
now the conformance bit 🎀 this is where the spec says what an implementation has to have to count as compliant. first up, the two containers for compliance statements and groups:
--
-- Conformance information
--
midcomCompliances OBJECT IDENTIFIER ::= { midcomConformance 1 }
midcomGroups OBJECT IDENTIFIER ::= { midcomConformance 2 }
--
-- compliance statements
--
-- This is the MIDCOM compliance definition ...
--
midcomCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for implementations of the
MIDCOM-MIB module.
Note that compliance with this compliance
statement requires compliance with the
ifCompliance3 MODULE-COMPLIANCE statement of the
IF-MIB [RFC2863]."
MODULE -- this module
MANDATORY-GROUPS {
midcomRuleGroup,
midcomNotificationsGroup,
midcomCapabilitiesGroup,
midcomStatisticsGroup
}
GROUP midcomConfigFirewallGroup
DESCRIPTION
"A compliant implementation does not have to implement
the midcomConfigFirewallGroup."
GROUP midcomResourceGroup
DESCRIPTION
"A compliant implementation does not have to implement
the midcomResourceGroup."
OBJECT midcomRuleInternalIpPrefixLength
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required. When write access is
not supported, return 128 as the value of this object.
A value of 128 means that the function represented by
this option is not supported."
OBJECT midcomRuleExternalIpPrefixLength
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required. When write access is
not supported, return 128 as the value of this object. A value of 128 means that the function represented by
this option is not supported."
OBJECT midcomRuleMaxIdleTime
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required. When write access is
not supported, return 0 as the value of this object.
A value of 0 means that the function represented by
this option is not supported."
OBJECT midcomRuleInterface
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT midcomConfigMaxLifetime
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT midcomConfigPersistentRules
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT midcomConfigIfEnabled
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT midcomConfigFirewallGroupId
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT midcomConfigFirewallPriority
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
::= { midcomCompliances 1 }okay so this is the part where the compliance statement spells out which objects only need read-only access, and it's giving very "you don't have to be able to write this, just read it" 💅
midcomRuleGroup OBJECT-GROUP
OBJECTS {
midcomRuleAdminStatus,
midcomRuleOperStatus,
midcomRuleStorageType,
midcomRuleStorageTime,
midcomRuleError,
midcomRuleInterface,
midcomRuleFlowDirection,
midcomRuleMaxIdleTime,
midcomRuleTransportProtocol,
midcomRulePortRange,
midcomRuleInternalIpVersion,
midcomRuleExternalIpVersion,
midcomRuleInternalIpAddr,
midcomRuleInternalIpPrefixLength,
midcomRuleInternalPort,
midcomRuleExternalIpAddr,
midcomRuleExternalIpPrefixLength,
midcomRuleExternalPort,
midcomRuleInsideIpAddr,
midcomRuleInsidePort,
midcomRuleOutsideIpAddr,
midcomRuleOutsidePort,
midcomRuleLifetime,
midcomRuleRowStatus,
midcomGroupLifetime
}
STATUS current
DESCRIPTION
"A collection of objects providing information about
policy rules and policy rule groups."
::= { midcomGroups 1 }
midcomCapabilitiesGroup OBJECT-GROUP
OBJECTS {
midcomConfigMaxLifetime,
midcomConfigPersistentRules,
midcomConfigIfBits,
midcomConfigIfEnabled
}
STATUS current
DESCRIPTION
"A collection of objects providing information about
the capabilities of a middlebox."
::= { midcomGroups 2 }
midcomConfigFirewallGroup OBJECT-GROUP
OBJECTS {
midcomConfigFirewallGroupId,
midcomConfigFirewallPriority
}
STATUS current
DESCRIPTION
"A collection of objects providing information about
the firewall rule group and firewall rule priority to
be used by firewalls loaded through MIDCOM."
::= { midcomGroups 3 }
midcomResourceGroup OBJECT-GROUP
OBJECTS {
midcomRscNatInternalAddrBindMode,
midcomRscNatInternalAddrBindId,
midcomRscNatInsideAddrBindMode,
midcomRscNatInsideAddrBindId,
midcomRscNatSessionId1,
midcomRscNatSessionId2,
midcomRscFirewallRuleId
}
STATUS current
DESCRIPTION
"A collection of objects providing information about
the used NAT and firewall resources."
::= { midcomGroups 4 }
midcomStatisticsGroup OBJECT-GROUP
OBJECTS {
midcomCurrentOwners,
midcomTotalRejectedRuleEntries,
midcomCurrentRulesIncomplete,
midcomTotalIncorrectReserveRules,
midcomTotalRejectedReserveRules,
midcomCurrentActiveReserveRules,
midcomTotalExpiredReserveRules,
midcomTotalTerminatedOnRqReserveRules,
midcomTotalTerminatedReserveRules,
midcomTotalIncorrectEnableRules,
midcomTotalRejectedEnableRules,
midcomCurrentActiveEnableRules,
midcomTotalExpiredEnableRules,
midcomTotalTerminatedOnRqEnableRules,
midcomTotalTerminatedEnableRules
}
STATUS current
DESCRIPTION
"A collection of objects providing statistical
information about the MIDCOM server."
::= { midcomGroups 5 }
midcomNotificationsGroup NOTIFICATION-GROUP
NOTIFICATIONS {
midcomUnsolicitedRuleEvent,
midcomSolicitedRuleEvent,
midcomSolicitedGroupEvent
}
STATUS current
DESCRIPTION
"The notifications emitted by the midcomMIB."
::= { midcomGroups 6 }
END10. Security Considerations ✨
Okay bestie, securing access to firewall and NAT configuration is extremely important for keeping the network safe 🔐. This section first covers the general security issues of the MIDCOM-MIB module, then gets into three concrete threats: unauthorized middlebox configuration, unauthorized access to middlebox configuration information, and unauthorized access to the MIDCOM service configuration 🚨.
10.1. General Security Issues
There are a bunch of management objects in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Those can be sensitive or vulnerable in some network environments 👀. But read-only objects can be sensitive or vulnerable too, so it's not just the write stuff. Doing SET and GET operations in a non-secure environment without proper protection can seriously mess with network operations 😭.
SNMP versions before SNMPv3 did not have adequate security. Even if the network itself is secure (for example, by using IPsec), there's still no control over who on that secure network gets to access and GET/SET (read/change/create/delete) the objects in this MIB module 🙈.
Deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED 💀.
Compliant MIDCOM-MIB implementations MUST support SNMPv3 security services, including data integrity, identity authentication, data confidentiality, and replay protection 🔒.
It is REQUIRED that the implementations support the security features provided by the SNMPv3 framework. Specifically, using the User-based Security Model RFC 3414 [RFC3414] and the View-based Access Control Model RFC 3415 [RFC3415] is RECOMMENDED 🌸.
After that, it's a customer/operator responsibility to make sure the SNMP entity giving access to an instance of this MIB is set up properly, so the objects are only accessible to the principals (users) who actually have legitimate rights to GET or SET (change/create/delete) them 🫶.
To make life easier for a security administrator setting up access control with the View-based Access Control Model (VACM) from RFC 3415 [RFC3415], the tables where multiple users may need to independently create or modify entries use the initial index as an "owner index" ✨. This is the case for the midcomRuleTable and the midcomGroupTable. Each of them uses midcomRuleOwner as the initial index. midcomRuleOwner has the syntax of SnmpAdminString, so it can be easily mapped to an SNMP securityName or a groupName as defined in VACM, in line with a security policy 💅.
All entries in those two tables that belong to a particular user will have the same value for this initial index. For a given user's entries in a particular table, the object identifiers for the information in those entries will have the same subidentifiers (except for the "column" subidentifier) up to the end of the encoded owner index 🧚. To set VACM so it allows access to this part of the table, you'd create vacmViewTreeFamilyTable entries with the value of vacmViewTreeFamilySubtree including the owner index portion, and vacmViewTreeFamilyMask "wildcarding" the column subidentifier. More elaborate configurations are possible 🌈.
10.2. Unauthorized Middlebox Configuration
The most dangerous threat to network security related to the MIDCOM-MIB module is unauthorized access to the facilities for establishing policy rules 💀. In that case, unauthorized principals would write to the midcomRuleTable to open firewall pinholes and/or create NAT maps, bindings, and/or sessions. Establishing policies can be used to get into networks and systems that are protected by firewalls and/or NATs 😱.
If that protection is removed by unauthorized access to MIDCOM-MIB policies, the resulting degradation of network security can be severe 🚨. Confidential info protected by a firewall might become accessible to unauthorized principals, attacks exploiting security leaks in systems on the protected network might become possible from external networks, and it might be possible to stop firewalls from blocking denial-of-service attacks.
MIDCOM-MIB implementations MUST provide means for strict authentication, message integrity check, and write access control to managed objects that can be used for establishing policy rules 🔒. These are the objects in the midcomRuleTable and midcomGroupTable with a MAX-ACCESS clause of read-write and/or read-create.
Write access to the managed object midcomRuleAdminStatus is especially sensitive, because writing to it causes policy rules to be established 🚨.
Writing to other managed objects in the two tables can also make security vulnerable if it interferes with the authorized establishment of a policy rule. For example, that could happen by wildcarding a policy rule after the corresponding entry in the midcomRuleTable is created, but before the authorized owner establishes the rule by writing to midcomRuleAdminStatus 🙈.
Not only unauthorized establishment but also unauthorized lifetime extension of an existing policy rule may be considered sensitive or vulnerable in some network environments. So, means for strict authentication, message integrity check, and write access control to the managed object midcomGroupLifetime MUST be provided by MIDCOM-MIB implementations 🫶.
10.3. Unauthorized Access to Middlebox Configuration
Another threat to network security is unauthorized access to entries in the midcomRuleTable 👀. The entries contain information about existing pinholes in the firewall and/or about the current NAT configuration. That info can be used to attack the internal network from outside. Therefore, a MIDCOM-MIB implementation MUST also provide means for read access control to the midcomRuleTable 🔐.
Also, a MIDCOM-MIB implementation SHOULD provide means for protecting different authenticated MIDCOM agents from each other. For example, an authenticated user should only be able to read entries in the midcomRuleTable where the initial index midcomRuleOwner matches the client's SNMP securityName or VACM groupName 💖.
10.4. Unauthorized Access to MIDCOM Service Configuration ✨
okay so this one is about the MIDCOM service's own settings 😬 there are three objects with a MAX-ACCESS of read-write that configure the service: midcomConfigIfEnabled, midcomFirewallGroupId, and midcomFirewallPriority 🔧
bestie, if somebody writes to midcomConfigIfEnabled without permission, it can cause serious interruptions of network service 💀 not a vibe at all
writing to midcomFirewallGroupId and/or midcomFirewallPriority is sneaky 🙈 those can bump the priority of the firewall rules that get generated when a policy rule goes into the midcomRuleTable (up or down, depending on what you write). raising the priority could let the rules from the MIDCOM-MIB module overrule basic security rules at the firewall that are supposed to win 😭 that's a whole plot twist nobody wants
so yeah, for these objects too, a MIDCOM-MIB implementation MUST provide means for strict control of write access 🔐🫶
11. Acknowledgements 🎀
this memo grew out of a long history of discussion inside the MIDCOM MIB design team 💜 huge thank you to Mary Barnes, Jeff Case, Wes Hardaker, David Harrington, and Tom Taylor for the fruitful comments and recommendations 🙌 and to Juergen Schoenwaelder, who acted as a very constructive MIB doctor 🩺✨
12. IANA Considerations 🌸
IANA has assigned an OID for the MIB module in this document 🦋
Descriptor OBJECT IDENTIFIER value
---------- -----------------------
midcomMIB { mib-2 171 }13. Normative References 📚
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC5189] Stiemerling, M., Quittek, J., and T. Taylor, "Middlebox Communication (MIDCOM) Protocol Semantics", RFC 5189, March 2008.
- [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
- [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
- [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.
- [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000.
- [RFC3411] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002.
- [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network Management Protocol Applications", STD 62, RFC 3413, December 2002.
- [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002.
- [RFC3418] Presuhn, R., Ed., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002.
- [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
- [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005.
- [RFC4008] Rohit, R., Srisuresh, P., Raghunarayan, R., Pai, N., and C. Wang, "Definitions of Managed Objects for Network Address Translators (NAT)", RFC 4008, March 2005.
14. Informative References 🧚
- [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002.
- [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002.
- [RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A. Rayhan, "Middlebox communication architecture and framework", RFC 3303, August 2002.
- [RFC3304] Swale, R., Mart, P., Sijben, P., Brim, S., and M. Shore, "Middlebox Communications (midcom) Protocol Requirements", RFC 3304, August 2002.
- [RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December 2002.
Authors' Addresses 🖊️
the three authors, all from NEC Europe Ltd. (plus Pyda Srisuresh at Kazeon Systems) 💌
Juergen Quittek
NEC Europe Ltd.
Kurfuersten-Anlage 36
69115 Heidelberg
Germany
Phone: +49 6221 4342-115
EMail: quittek@nw.neclab.eu
Martin Stiemerling
NEC Europe Ltd.
Kurfuersten-Anlage 36
69115 Heidelberg
Germany
Phone: +49 6221 4342-113
EMail: stiemerling@nw.neclab.eu
Pyda Srisuresh
Kazeon Systems, Inc.
1161 San Antonio Rd.
Mountain View, CA 94043
U.S.A.
Phone: +1 408 836 4773
EMail: srisuresh@yahoo.comFull Copyright Statement ⚖️
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 💜
the IETF takes no position on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or on whether any license under such rights might or might not be available, and it doesn't claim to have made any independent effort to identify any such rights 🤷♀️ info on how rights work for RFC documents is in BCP 78 and BCP 79 📖
copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt to get a general license or permission for implementers or users are available from the IETF on-line IPR repository at http://www.ietf.org/ipr 🔗
the IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology required to implement this standard 🦋 send that information to ietf-ipr@ietf.org 💌
📦 where this page comes from
- ietf: rfc5190 2008-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms