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

RE: New IPSec Monitoring MIB draft



Howdy ()
	I have some questions about the ipsecProtSuite Table and identities.
 
Suppose that I have an IPSec SA bundle made up of one AH SA and one ESP SA
and one Comp SA. This bundle was built as a unit by a single IKE negotiation
with a single peer.


So now I have in my box one each of:
  	ipsecProtSuiteInboundEspSpi
	ipsecProtSuiteOutboundEspSpi
  	ipsecProtSuiteInboundAhSpi
	ipsecProtSuiteOutboundAhSpi
  	ipsecProtSuiteInboundCompCpi
	ipsecProtSuiteOutboundCompCpi
  	
Where ipsecProtSuiteLocalAddress and ~RemoteAddress are the same for all the
above.

Now I build a query for some statistical value (ex PolicyErrors)of a
ProtSuite and get the whole table as ordered by 'index'

I expect to get the "total number of inbound packets discarded [...] due to
policy errors" which have passes across these THREE SAs since there
instantiation (don't sweat counter wraps for this discussion) at one single
indexed table entry.

But, (and here come my questions) Is there a way to monitor individual SAs?
Can I expect an indexed entry for EspSpis with 0 for the AH and Comp
Spis/Cpis? Would I then get the total number of inbound packets discarded
due to policy errors on just the ESP SA? This seems a little cumbersome to
dig into individual SAs and also seems to allow enough ambiguity to muck
with inter-vendor consistency.

Did/could we consider an approach where we have a table of ESP SAs, a table
of AH SAs, a table of Comp SAs and then a table of ProtSuite bundles which
refers to appropriate values (or formulas of values) from those first three?

Now let me anticipate the question, "What would be the value of measuring
individual SAs?"

First, I acknowledge that measuring statistics on "protSuites" is very
useful!  This closly paralles link monitoring which is of highest concern to
O&M groups. I certainly believe that protSuite measuring (as opposed to
individual SA measuring) will be the most common application for this mib
and be the most customer demanded feature (just my gut feeling, not any
official survey). 

But I see three needs for finer grain visibility into IPSec devices. 
  1. drill down trouble shootin' for finer fault isolation
  2. pattern recognition to identify attack profiles
  3. device capacity monitoring, so that total number of SAs may be 
      tracked as well as traffic count summations on comp, ESP and AH
  

So, I know this is a BIG SHIFT from the proposal (which has just undergone a
BIG SHIFT). Let's talk it out... what do Y'all think?

###################################
#  Ricky Charlet
#   rcharlet@RedCreek.com
#  (510) 795-6903
###################################
end Howdy;