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

Re: FW: IPSec Monitoring MIB works for IPv4 only?

I don't think that's a suitable solution, but that's because I think
that the ipSecSaTable just isn't right in the first place.

I'm working with a major customer with extensive experience in
operating managed networks.  They have worked with us to design a
proprietary MIB for IPsec for our product.  In that MIB, the SA table
has one entry for each SA (not a stack of SAs).  The key is the three
variables that uniquely identify an SA in The Internnet: destination
IP address, SPI, and protocol { ESP, AH }.

The reason is that they want to be able to troubleshoot effectively
over low-bandwidth links.  They want to know why packets sent to this
box with a particular SA aren't working.  They cannot search the
entire SA table looking for the entry they want.  Instead, the table
needs to be indexed by the data in the table.  A MIB is a database.
It needs to be an efficient database.  Efficient databases are not
ipmlemented using grep (especially on the output of an snmpwalk)!

It is NOT hard to implement an SNMP table with this sort of
triple-index.  You just have to design the data right, I've done it
many times now.  Making our coding easier should not be justification
for designing structurally flawed MIBs.

One certainly could eliminate one index by having seperate tables for
AH and ESP SAs.  (Looking at the data, some is specific to AH SAs,
and some is specific to ESP SAs, so that split appears logical to me.)

Another reason that the ipsecSaTable is flawed is that some of the
variables do NOT have the same values for the four SA's that have been
lumped together.  The ipsecSaCreationTime most certainly will not be
the same.  There is no requirement in the IKE protocol that
ipsecSaTiemLimit and ipsecSaTrafficLimit be the same for the four
SA's.

Moreover, the attempt to aggregate the traffic statistics at that
"tunnel" level is innapropriate.  There has to be a traffic counter
for both the AH and ESP SA's, after all they each can have a traffic
limit.  So, one can't try and merge them into one counter to prevent
the MIB from requireing "excess instrumentation", since the
instrumentation is necessary to implement the protocol correctly.

There is nothing wrong with a table that says what SA's a given
"tunnel" uses.  But it's mostly a cross-reference table.  The tables
for the SA's must be by the SA.

As for IPv6, we can add seperate tables for IPv6 AH and ESP SAs.  It
really is a seperate numbering space.  I'd suggest that they probably
belong in a seperate MIB, because we don't want the IPv4 parts of the
MIB to get hung up waiting for the IPV6-TC MIB to reach RFC status so
it can be cited as a reference.  IPsec cannot afford delays caused by
excess dependencies.


(I'll have more comments on other tables...)
Follow-Ups: References: