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

RE: Status of ID: IPsec Flow Monitoring MIB

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: