[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: New IPSec Monitoring MIB draft
---
Tim Jenkins TimeStep Corporation
tjenkins@timestep.com http://www.timestep.com
(613) 599-3610 x4304 Fax: (613) 599-3617
> -----Original Message-----
> From: Ricky Charlet [mailto:rcharlet@redcreek.com]
> Sent: Friday, January 29, 1999 4:48 PM
> To: 'Tim Jenkins'; 'ipsec@tis.com'
> Subject: 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?
No, but remember, the selectors for all SAs in the protection suite are the
same. This means (in the case of policy errors) that the policy rule for the
packet says "Apply ESP+AH" (for example), not "Apply ESP and then check to
see of AH should be applied". The latter is not a protection suite, but it
is still an SA bundle.
In that case the protection suite table would have at two entries. One entry
puts ESP on the packet, while the second puts AH on the ESP packet that
resulted from the first encapsulation.
> 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.
I'm not sure what you're asking here. Protection suites with no ESP have an
ESP SPI of 0; all the stats and error apply to the AH/IPCOMP if they are
used.
>
> 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?
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.
>
> 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
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.)
>
>
> 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;
>