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

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

Tim Jenkins wrote:
> My mandate was to *quickly* produce a usable MIB. The speed issue requires
> some simplification. 

Who mandated speed over good design?

> Further, I have only made a few simplifications:
<trimmed...>

> 2) No method to specify the order of the services per bundle, since the
>    normal reasonable order is assumed (see some of the previous email on
>    this).

No substantive comment, though my gut reaction is that this may bite us
later.

> 3) Only 1 phase SA between 2 peers at a time.

Bad assumption, just plain wrong. The design provides the capability to
maintain an arbitrary number of phase 1 SAs between peers, and this is a
useful capability. It should not be restricted.

> 4) That IPSec is above IP in a stack.

No, IPsec is *in* the IP portion of the stack. If it were above IP, you
could not look at the IP headers of incoming packets, as they would
already have been stripped. Hence, you could not possibly authenticate
them using AH.

<trimmed...> 
> > This brings up another issue.  I think "tunnel" is not the word to use
> > here.

I made this point on the ipsec-errors list, and I'll reiterate my
reasoning. IPsec is very complex. In order to implement (or just
understand) it you must wade through the ARCH, ISAKMP, ESP, AH, DOI, and
IKE documents, probably all at the same time, skipping back and forth.
You already know what a daunting task this is. Why complicate this
further by overloading the word 'tunnel', which is integral to the
architecture, in this manner? This only serves to confuse and confound.

> > In your own response, you flip between "tunnel" and "bundle".
> > Since "bundle" is what is used in the IPSec Architecture document, I
> > think it would be a better-chosen word to use for what the
> > ipsecSaTable contains.  Thus, I'd propose we call it the
> > ipsecBundleTable...
> 
<trimmed...>

> I also wanted to strengthen the concept that bundles are SAs with multiple
> services, rather than simply layered SAs.

The concept you want to strengthen is wrong - here's the definition from
ARCH:

   A Security Association (SA) is a simplex "connection" that affords
   security services to the traffic carried by it.  Security services
   are afforded to an SA by the use of AH, or ESP, but not both.  If
   both AH and ESP protection is applied to a traffic stream, then two
   (or more) SAs are created to afford protection to the traffic stream.

Clearly, SAs provide a single service.
References: