[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Status of ID: IPsec Flow Monitoring MIB


Hi -

   From: "Shriver, John" <john.shriver@intel.com>
   Date: Tue, 30 Oct 2001 11:28:41 -0800

  >***** This is not the VPN working group.
  >      This is the IPsec working group.
  >*****

Good. We are on the same page.


  >Our job is to develop useful MIBs for the "protocol" named IPsec.
  >It consists of ESP, AH, static keying, ISAKMP, and IKE.

Whether its "useful" depends on what requirements you
you are seeking to address by the design. Exactly what are they?
Or did the IPsec WG say "Gee, we designed a protocol and
now lets have a MIB to go with it"?

  >You may validly pick on the monitoring MIBs in that [...]

Specific objections:
  1. you have too many layers of MIBs and makes the implementation
     of SNMP manageability expensive
  2. you acknowledge further that abstractions and correlations
     (such as those defined by us) are needed on top of these
     bit-level MIBs, adding more cost to the implementation.
  3. the structures you define are too ephemeral to be of much
     value. Flows are steady; your "suites" change with every
     QM. An NMS that wants to monitor the summary status of
     traffic flows would have to juggle multiple suites. Such
     applications would be complex.

Now to your criticisms:

(a)
   >But, as for layering IPsec (AH and ESP proper) separately from
   >ISAKMP/IKE, nobody has published a revision of RFC 2401 that
   >makes ISAKMP/IKE mandatory for IP Version 4.

This is a valid point and we plan to fix this in a more general
way than you have. Your dedicating a whole MIB to a specific
keying protocol is problematic (but that's a different discussion).

(b)
  >The idea of SNMP was never that users would "understand" a MIB.

I couldn't disagree more. A well-defined MIB for a technology
would summarily reflect the working of the technology, just as
a database schema for an application reflects the essence of
the application.
If you can't understand the essence of a technology modelled by
the MIB designed for the technology, please blame the MIB designer.

(Btw, users of managed entities often times inspect the
conformance clauses in the supported MIBs - for obvious
reasons.)


(c)
  >I don't see that the Flow Monitoring MIB would be very useful
  >for "opportunistic IPsec" with transport mode.

Please elaborate. I do not see how the Flow Monitoring MIB
would fail with opportunistic encryption.

I am disregarding your comparison of the details because
we have a basic problem with your proposals: I believe that
the MIB should judiciously combine abstractions with low
level details while at the same time providing back and forth
correlations between the two views.

Your proposal is lopsided with too many details and no
abstractions; this makes management complex.

Thanks,

Rk
x77309

---
S Ramakrishnan, Cisco Systems Inc., San Jose, Ca
References: