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

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

   From: Tim Jenkins <tjenkins@TimeStep.com>
   To: John Shriver <jas@shiva.com>
   Date: Wed, 18 Nov 1998 13:34:29 -0500


   > -----Original Message-----
   > From: John Shriver [mailto:jas@shiva.com]
   > To: tjenkins@TimeStep.com
   >
   > There's no question that my proprietary MIB also has "tunnels".  There
   > are plenty of useful things there.  But there really ought to also be
   > a fast way to find your way into the MIB if the only thing you know is
   > the destination IP address and SPI.
   > 

   This would require the addition of an IP address added to every
   'ipsecSaEntry',
   causing it to be duplicated, since it's already in the 'ipsecIkeSaTable'.

   > I think my customer is looking at the "troubleshooting" part of
   > management, and your customer is looking at the "performance
   > monitoring" part of management.  Both are valid, and both should be
   > represented in the MIB.  (See Perkins' book.)
   > 

   Sure, but if there's a conflict between the two, which has priority?
   You can still do both with this architecture, it's just easier to do
   performance monitoring. Which would be done more often by most customers?

   Would it help if an 'ipsecIkeSaTable' index was placed into each
   'ipsecSaEntry', so that one de-referencing step would be removed?
   Is it worth it?

That doesn't address the issue.  My customer needs to get the data in
the minimum number of bytes over the extremely slow link to the IPSec
device.  Anything that requires reading the entire table is a no-no.
(We tried to convince him.)

There doesn't need to be any data other than cross-reference in the
table indexed by IP destination address and SPI.  Using SNMP exchanges
is OK, it's the whole table search that's the killer.  The only other
thing needed is a pointer to the "bundle" or Phase 2 SA.  It's just an
efficient lookup key.

Your system can require loading the entire contents of two or three
tables (due to avoidance of "duplicate" variables), cross-correlation,
and search.  This is worst case if you need to find the Phase 2 SA
corresponding to an out-going SPI.

I don't think that duplicate variables are evil when they allow you to
make meaningful indices.
References: