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

[Tim Jenkins <[e-mail]>]

---
Tim Jenkins                       TimeStep Corporation
[e-mail]          http://www.timestep.com
[phone] x4304               Fax: [phone]


> -----Original Message-----
> From: Scott G. Kelly [mailto:[e-mail]]
> Sent: Friday, November 20, 1998 4:12 PM
> To: Tim Jenkins
> Cc: [e-mail]
> Subject: 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. 

Accepted. I'll try to remember to put on my kevlar-and-asbestos lined jacket
from now on anyway.

> 
> 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.
> 

I agree with the last of this only if the selectors are different. Dan
Harkins has (a number of times) pointed out difficulties with bundling
separately negotiated SAs with the same selectors and different protocols
(ESP, AH or IPCOMP).

IMO, the negotiation of a new SA with a different protocol than the previous
one is that a re-keying just took place, and the policy was also changed.

As others have said: If you want bundled service with the same selectors,
negotiate them at the same time. This means to use a protection suite.

<snip>

> > 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.
> 

Yes, it's 6.

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

I had long discussions with one of our longest customers on this, I believe
John Shriver preferred that route, and perhaps others.

> > 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).

>From 'case 1' of section 4.5 of the architecture document:

<start quote>
        Note that there is no requirement to support general nesting,
        but in transport mode, both AH and ESP can be applied to the
        packet.  In this event, the SA establishment procedure MUST
        ensure that first ESP, then AH are applied to the packet.
<end quote>

I read this as saying that for simultaneously negotiated SAs (a protection
suite), the processing of AH before ESP (outbound) IS illegal. As such, the
MIB won't explicitly support it.

Further, from section 2 of <draft-ietf-ippcp-protocol-06.txt>

<start quote>

   The compression of outbound IP datagrams MUST be done before any IP
   security processing, such as encryption and authentication, and
   before any fragmentation of the IP datagram.  ...

<end quote>

I read this as saying that for simultaneously negotiated SAs (a protection
suite), the processing of ESP or AH before IPCOMP (outbound) IS illegal.

This leads to a simple conclusion: for protection suites, there is only one
possible order of application of protocols (outbound): IPCOMP before ESP
before AH.

There's nothing in the MIB that prevents the presentation of separately
negotiated SAs with the same selector with different services. However, they
won't show up in what was called the ipsecSaTable as a single entry; they'll
just take two entries in that table. (Table is now called
ipsecProtSuiteTable.)

Further, if you insist on negotiating the outbound application of AH before
ESP with the same SA selectors, you can still do that; it's just that the
current MIB won't be able to show the order of application. Should it? I
don't think so. Like I said, I view the separate negotiation (when the SA
selectors are the same) as a re-key, not bundle creation.

Further again, if you really want AH before ESP, it can be done by
specifying policy that says creates ESP SAs with AH as the selector, and
making sure packets pass through your SPD/SAD twice before they get out of
your implementation.