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

["Scott G. Kelly" <[e-mail]>]

I wrote:
> > 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.
<trimmed...>

Tim wrote:
> 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.

<trimmed...>
 
I understand what you're saying here, but I think there is an ambiguity.
Just prior to the text you quote (also in section 4.5) is the following
text:

<begin quote>
   This section describes four examples of combinations of security
   associations that MUST be supported by compliant IPsec hosts or
   security gateways.  Additional combinations of AH and/or ESP in
   tunnel and/or transport modes MAY be supported at the discretion of
   the implementor.  Compliant implementations MUST be capable of
   generating these four combinations and on receipt, of processing
   them, but SHOULD be able to receive and process any combination.  The
   diagrams and text below describe the basic cases. 
<end quote>

I take this to mean that any combination is possible. I take the text
you quote to mean that for case 1, the specific ordering is a defining
characteristic of this particular case.

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

I agree with the sensibility of this approach in most cases, i.e. it
doesn't make sense to try to compress ostensibly random data. However,
it might make sense to compress authenticated data in some cases. In any
event, since the draft in question originated outside of this wg, I'm
not sure we should cite it as a constraining authority for ipsec
implementations.

<trimmed...>

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

I guess this is the bottom line. This means there is a (new) mechanism
for representing arbitrary nesting of SAs, although it may not be
optimal. I guess that addresses my concern.

Scott