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

RE: New IPSec Monitoring MIB draft

Ricky Said
> > 
> > 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?
Tim Said
> 
> I did look at this. However, ISAKMP explicitly states that 
> protection suites
> are to be treated as a single unit. The multi-table approach 
> was much more
> complicated, and did not add what I believe significant value.
> 
Ricky Said
> > 
> > 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

Tim Said
> 
> I'm not sure that multiple tables will give you any 
> significant benefit for
> points 1 and 2, given the nature of protection suites.
> 
> Even for point 3, if you want to measure the total traffic 
> that has ESP
> applied to it across all protections suites, you add up the 
> traffic serviced
> by all protection suites that have ESP. That's because the user level
> traffic reported by ESP+AH, ESP, and AH protection suites 
> should be the
> same. (Even with IPCOMP, the user level traffic reported 
> should still be the
> same.)
> 




OK, your points are well reasoned. But I am still having trouble with
shutting the door on the ability to observe individual IPSec SAs. The
complexity involved in creating three more tables to track individual ESP,
AH, and COMP SAs is not much of a problem. When he ISAKMP doc says that
"protection suites must be considered as a unit" it means for the purposes
of determining the acceptability of a proposal. That sentence should not be
taken to imply that ISAKMP requires that the individual security
associations making up a proposal not be monitored in their own right. By
not allowing the MIB to watch stats on individual IPSec SAs, you have
artificially constrained the functionality down from IPSec monitoring to
ISAKMP monitoring.

Again, please know that I do agree that monitoring stats on a protection
suite is probably the most important function of this MIB. It is the "Big
Rock" which must be placed in the jar first. If we all go ask our customers
if they want to monitor traffic flow stats down protections suites, I posit
the answer is a resounding "YES, that's it exactly!!", But if we also ask
our customers if it would be ok to NOT monitor individual Security
Associations, I posit here the answer would be just as resounding, "NO!".


	I wonder if I am a 'lone ranger', 'ranting wild man in the
wilderness' on this 'individual SA monitoring' issue. Are there others out
there who have an opinion?


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