MIDCOM MIB Juergen Quittek, Martin Stiemerling, Pyda Srisuresh 60th IETF meeting, MIDCOM session

IETF 60 MIDCOM MIB2 Changes Since Version -00 A lot of editorial changes  added a lot of clarifications  renamed signaling group to transaction group  added entity relationship diagram for MIB tables Added Section 7 on Usage examples for monitoring resources (NAT, firewall)  not yet complete (firewall part is missing) Completed Security Considerations

IETF 60 MIDCOM MIB3 Issue 1: MIB Structure Changes MIDCOM MIB Tables  Session Table  Rule Table  Group Table  Capabilities Table  IP interface configuration  Notifications  Firewall Configuration Table  Resource Mapping Table  Session and Rule Statistics implementing MIDCOM semantics add on's Proposed changes in structure  Merge firewall Configuration table and Capabilities table?  Replace session table by Target MIB and/or Notification MIB? next version needs study

IETF 60 MIDCOM MIB4 Issue 1: MIB Structure Changes Removing Session Table  The session table mainly serves for  subscribing to notifications  distinguish MIDCOM clients using the same SNMP manager  Instead of specifying a session table, the existing Target MIB and/or Notification MIB should be used.

IETF 60 MIDCOM MIB5 Issue 2: Firewall Configuration Request for more detailed assignment of firewall priority Currently, we have the same priority for all rules per interface. This is OK even for overlapping rules since we decided to have allow actions only and no deny actions. Issue solved.

IETF 60 MIDCOM MIB6 Issue 3: Notification Subscription No means for configuring which notifications to receive  Which essential transaction needs notifications? Supported Notifications  Session termination  Rule event  Group event Alternative solutions:  adding a BITS object to session table  or use Target MIB / Notifications MIB

IETF 60 MIDCOM MIB7 Issue 4: Idempotency MidcomRuleLifetime can have idempotency failures  resulting in longer lifetime than intended  depending on SNMP retransmission timeout  in general the longer lifetime will be known by the MIDCOM agent  Solution: The total lifetime needs to be stored  either at the MIDCOM server (additional managed object)  or at the MIDCOM client (additional client state)  preference: use additional managed object in rule table There are further idempotency problems with session index and rule index generated from session table  These will probably disappear, if the session table is replaced

IETF 60 MIDCOM MIB8 Issue 5: MaxIdleTime Should the default be  using the NAT's default maximum idle time?  would require an additional object that reports the default idle time  or disabling the max idle time mechanism?

IETF 60 MIDCOM MIB9 Issue 6: MaxIdleTime for PRR Is MaxIdleTime an input parameter to PRR?  MIB uses a Lifetime attribute for each policy rule  Additionally, for each policy rule, a MaxIdleTime attribute can be defined  specifies an idle time after which the policy may be removed  The Policy Reserve Rule (PRR) does not contain any action affecting packets, it just reserves resources to be used by a policy.  Solution: make it an optional parameter to PRR

IETF 60 MIDCOM MIB10 Issue 7: Naming Conflict Naming conflict between MIDCOM terminology and NAT terminology  MIDCOM semantics uses internal/inside and external/outside  NAT MIB uses privateSource/privateDestination and publicSource/publicDestination  Solution: use one of them consistently

IETF 60 MIDCOM MIB11 Recently Raised Issues midcomRuleNatService  raised by Suresh  For what kind of middleboxes is this object useful? midcomInsideInterface and midcomOutsideInterface are missing  raised by Bob Penfield  to be discussed RuleLifetime and/or RuleMaxIdletime differ for policy rules using the same resource