[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: FW: IPSec Monitoring MIB works for IPv4 only?
---
Tim Jenkins TimeStep Corporation
tjenkins@timestep.com http://www.timestep.com
(613) 599-3610 x4304 Fax: (613) 599-3617
> -----Original Message-----
> From: John Shriver [mailto:jas@shiva.com]
> Sent: Wednesday, November 18, 1998 10:27 AM
> To: tjenkins@TimeStep.com
> Cc: ipsec@tis.com
> Subject: 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 }.
And we're working with a major customer with extensive experience in
operating managed networks, too. They have (relatively) no interest
in the individual SAs themselves, but only the virtual tunnels created
by those SAs. The existing design is intended to be more efficient for
that point of view, rather than the low level diagnostic at the
individual SA point of view.
>
(some deleted here)
>
> 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.
What 'four' SAs are you referring to?
I think you're mixing layered SAs (multiple independently negotiated SAs)
with SA bundles. While you are technically correct about lifetime
specifications in an SA bundle, there is no practical way to re-key
one of the services in a bundle if it expires before the other. The
prevailing view is that SA bundles are relatively tightly bound services
that effectively make up a single SA with multiple services.
As an example, if an IPCOMP+ESP+AH SA bundle is negotiated between
two peers, and the ESP part expires first, it is likely that the entire
SA will be torn down. I stated in the document that the assumption is
that the SA bundle lives only as long as the shortest living service
in the bundle.
Absolutely no one has complained about this. There's a trade-off between
being all-encompassing and being practical; perhaps I err on the side
of practicality in my assumptions.
>
> 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
There is. There statistics for individual SAs, statistics for the tunnel
they represent, and aggregates statistics between peers.
Why is it inappropriate to have tunnel statistics? That's what users see.
They really don't care how many SAs lived and died in a given time period
as long as the security service is there.
> 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.
Again, there is an SA table. While you have to get to it from another
table to get its selectors, all the individual SA statistics and
information are there.
>
> 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.
>
Does this mean you recommend that the existing MIB ignore the IPv6 address
issue for now?
>
> (I'll have more comments on other tables...)
>
Follow-Ups: