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

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

First, I'd like to apologize to all concerned for this exchange:

Tim Jenkins wrote:
> > > > > My mandate was to *quickly* produce a usable MIB. The speed
> > > > issue requires
> > > > > some simplification.
> > > >
> > > > Who mandated speed over good design?
> > >
> > > Gee, nice snipe, Scott. Got anything constructive to say?

I've given this a bit of thought, and I think I could have phrased my
thoughts differently. Please accept my apology. 

I've trimmed most of the Tim's latest reply on this thread, and will
limit my response to a few issues.

> 
> No, you haven't mis-interpreted me. Please read section 4.2.1
> of the ISAKMP document. You'll see an example there:
> 
> <begin quote>
> This second example shows a Proposal for two different protection suites.
<trimmed...>

I was using the section 2.1 definition, and had (apparently incorrectly)
interpreted this to mean that the protection suite falls within the
protocol (AH or ESP), but did not encompass both. After rereading your
examples and other portions of the doc, I see what you mean. This taps
into another issue which I think Markku has touched on, that being that
the SAs in the kernel are really independent of ISAKMP, IKE, SKIP, or
whatever you used to negotiate them. Hence, for an ipsec monitoring mib,
maybe the definitions should also be independent of the SA/Key mgmt
subsystems.

> Protection suites are a subset of SA bundles, as defined in section 4.3
> of the architecture document.

I guess I would say the protection suites, an ISAKMP construct, are a
direct mapping of SA bundles, an architecture construct. However, they
do not represent the only mapping. As others have noted, the SAs could
be negotiated individually, and only bundled at the kernel level.

> Fine, I'll add another table, that splits out the actual phase 1
> SAs from the phase 1 tunnel table. (Would "channel" be a better
> word here?)

Not sure - still thinking about this one.

> For the phase 1 tunnel table, the only other word that appears
> appropriate so far is "channel", since the phase virtual tunnel
> is really a control channel for SA negotiation. Comments on this?
> 
> For phase 2, though, I think tunnel is the right word, if for
> no other reason that many implementations want this to be tied
> to the tunnel interface MIB. They really are tunnels, anyway.

Wait, you lost me. Say that between 2 SGWs I have 3 tunnel-mode
(protocol) SAs. Up until now, I would say I have 3 tunnels. If I had 2
GRE tunnels in addition to these, I would say I have 5 tunnels. If (for
some reason) I also had a L2TP tunnel, then I would say I have 6
tunnels. How many tunnels would you say I have? If your answer is not 6,
please explain your reasoning.

Also, who specifically wants this tied to the tunnel interface mib?

> The SA bundle issue is somewhat related to the MIB design. The MIB supports
> only two kinds of SA bundles: protection suites as defined in ISAKMP,
> and interated tunneling when the selectors for the negotiated SAs are
> different.

What I have been trying to express is that the mib should support any
legal SA bundle as defined in the architecture document. My comments
regarding rigid ordering, e.g. [AH][ESP][IPPCP], were based mostly on
the fact that the architecture doc does not forbid other orderings, but
rather does not mandate support for more than a few likely ones. This
doesn't mean others are illegal, only that support for them is not
required. So long as they are not illegal, it is somewhat probable that
some other orderings will occur, in which case the mib would be broken.
This bothers me (a little).

Scott
Follow-Ups: References: