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

Re: Status of ID: IPsec Flow Monitoring MIB

I believe all of points were addressed by rks in his response
to Tim Jenkins (timestamp Tue, 30 Oct 2001 12:21:11 -0800).
His responses were great and right-on-the-money.

I would like to add several comments...

1) Your note is very interesting and touching.  It covers 
   all the points that one learns in an "how to influence
   others" class - fear, justification, authorization advice 
   and ends with sympathy.  Very nice.

2)  However, I would really like the IPsec Group to 
    have a MIB which is useable/meaningful.  The "bit level" MIB 
    drafts are not even close.  
    
    I work with VERY competent developers (in other areas) 
    who cannot make sense of these "bit level" MIBs and 
    use IPsec.  And then there are the application developers, 
    network operators, and poor users which find the "bit level" 
    MIBs COMPLETELY meaningless. They do not understand the 
    objects or their meaning.  NOT good and NOT normal in other MIBs. 

3) The "bit level" MIBs have not been widely accepted,
   implemented nor gone though review/updates based on
   on experience.  A real issue for standardization and
   moving forward.

4) On the other hand, the Flow Monitoring MIB has.

   This MIB been implemented in at least 4 FAMILIES
   of products for 3 different vendors/implementors
   that I have worked for and has undergone at least
   5 revisions based on input/feedback from developers 
   to customers.

It continues to be my belief that the "bit level" MIBs
should be abandoned as they are not useful and move to 
a useable MIB IPsec which ALL can understand and use
to make the protocol VERY manageable.  
     


"Shriver, John" wrote:
> 
> I think I need to remind the participants of this discussion of an important
> point:
> 
> ***** This is not the VPN working group.  This is the IPsec working group.
> *****
> 
> I think this has been emphasized MANY times by the chairs and area
> directors.  They will NOT budge on this issue.
> 
> The phrases "VPN" and "Virtual Private Network" do not appear in our
> charter.  Please re-read it:
> http://www.ietf.org/html.charters/ipsec-charter.html
> 
> Our job is to develop useful MIBs for the "protocol" named IPsec.  It
> consists of ESP, AH, static keying, ISAKMP, and IKE.
> 
> I will not claim that the IPsec Monitoring MIBs are trivial to implement.
> Nor is IPsec trivial to implement.  Many complain that it is too
> complicated, the MIBs make the complexity visible.  Much of that complexity
> is in the extreme flexibility of IPsec.
> 
> If you want to make the MIBs simpler, please propose which options to delete
> from IPsec.  (That is a relatively rhetorical question, I do NOT want to
> drag THAT discussion into this discussion!)
> 
> You may validly pick on the monitoring MIBs in that we split ISAKMP and IKE,
> and that the working group has since decided that said layering of
> documentation and specification is no longer appropriate.  Fine.  It would
> be a trivial change to the monitoring MIBs to merge the ISAKMP and IKE
> documents into one MIB.  For the most part, the tables in the IKE MIB merely
> augment tables that already exist in the ISAKMP MIB, so it's just a matter
> of stiching them into one table.  It would also allow us to remove the
> columns in the "ISAKMP" tables that say "this row is IKE".
> 
> 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.
> 
> I think that the MIBs do provide the lookup tables to examine the status of
> one "phase 2 security association suite".  I do not think that these are
> generally so short-lived that an SNMP manager could not find it before it
> was replaced with a new one (rekeying, I presume).  (Maybe I'm wrong on
> this, maybe the bandwidths are now so high that rekeying is done once a
> minute.)
> 
> > And should replace the "low level" MIBs which no one other than
> > an IPsec developer could understand.
> 
> The idea of SNMP was never that users would "understand" a MIB.  I think
> that the providers of SNMP management stations were supposed to provide the
> "understanding".  Unfortunately, a lot of them never got past MIB walkers
> and pretty network maps that turn nodes red and green.  This is partly
> because the MIB syntax isn't really very descriptive, is weak on explaining
> table relationships, etc.  This also leads to people wanting to write flat
> "application-specific" MIBs, because all the layering has to be described in
> text, rather than as a formal part of the syntax.
> 
> I'm interested in knowing what particular parts of these monitoring MIBs
> people think are really useless.  I do know that there are places where only
> one type of "identity" make any sense, yet we support any of the defined
> ones, because ISAKMP/IKE does.  So let's strike those, hopefully they will
> also be striken in the "son of IKE" document.
> 
> I don't see that the Flow Monitoring MIB would be very useful for
> "opportunistic IPsec" with transport mode.
> 
> Looking just at the IKE phase 1 area, you have two tables.  One is
> ikePeerTable, which is about concrete peer entity relationships.  That's a
> layer we don't have, and is a table I agree is useful.  It is in turn
> layered on ikeTunnelTable.  That is quite equivalent to our saTable, in
> particular the rows that show up in ikeSaTable.  The contents of
> ikeTunnelTable and ikeSaTable are quite comprable.  The difference is that
> you cannot do a meaningful direct lookup of ikeTunnelTable, since it is
> indexed by a "meaningless" arbitrary index.  The ikeSaTable is indexed by
> the "real" fields of the ISAKMP/IKE negotiation that identify one Phase 1
> connection.
> 
> It would be quite simple to expand ikePeerTable to have the full index data
> to identify a real ISAKMP/IKE phase 1 tunnel (address types, addresses, and
> cookies), and then replace ikeTunnelTable with a merged saTable/ikeSaTable.
> 
> I also note that ikeTunnelTable has even more statistics than ikeSaTable.
> Nothing wrong with that.  The more the merrier.
> 
> However, there is a visible strategy difference on how the two MIBs count
> exchanges.  ikeTunnelTable keeps  some global counters of all exchanges, and
> then has counters for each of the exchanges currently defined.  This means
> that the MIB will require revision every time a new exchange gets defined,
> and will never reach Full Standard status.  (I've been in that endless loop
> on other MIBs, like the dot3 MIB.)  We put in a table for counting
> exchanges, exchangeTable, that is indexed by the same indices as ikeSaTable,
> plus an additional index of the exchange type.  (Think of it as another
> dimension on ikeSaTable.)  This means that we don't need to revise the MIB
> when a new exchange type is assigned, the IANA edits the textual-convention
> MIB, and the new rows magically exist.
> 
> I would also note that the Tunnel MIB doesn't conform to RFC 2581.
> 
> I will admit that our progress has been slow.  Some of the drafts expired.
> Neither of us are developing IPsec products for a living anymore, we
> finished this project out of a dedication to the needs of this IETF working
> group, and (slowly) living up to our committments thereto.
Follow-Ups: References: