---
Tim Jenkins TimeStep Corporation
tjenkins@timestep.com http://www.timestep.com
(613) 599-3610 x4304 Fax: (613) 599-3617
> -----Original Message-----
> From: Scott G. Kelly [mailto:skelly@redcreek.com]
> Sent: Thursday, November 19, 1998 1:12 PM
> To: Tim Jenkins
> Cc: John Shriver; ipsec@tis.com
> Subject: 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?
Gee, nice snipe, Scott. Got anything constructive to say?
>
> > 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.
This, and I've said this before, was apparently already decided
long ago. Dan Harkins has posted it at least twice, and further,
the architecture document itself says that ESP must be applied
before AH. This is perfectly enforcable in the context of a
protection suite as defined by the isakmp draft.
See the "Appendix" below.
>
> > 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.
Having cut my questions as to why you should support more than
one, you avoid having to answer, I guess.
The reality is, unless I can be convinced I need to keep
more than one, as soon as you successfully negotiate a new
phase 1 with me, there is nothing in the documents that says
I can't send you a delete notification for the old and stop
using it. Hell, I'm not even *required* to send you a delete
notification, I can just stop using it.
So I ask again: Why *should* we support more than one phase 1
SA? ("Because we can" is not a good enough answer.)
>
> > 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.
>
Now you're arguing implementation versus conceptual. Conceptually,
since many implementations apply IPSec to non-fragmented IP packets,
it may be viewed as on top.
In any case, it doesn't change the logic for not binding the virtual
phase 2 tunnels to the interface MIB. It's implementation specific,
so it can be handled in other ways.
> <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.
And the last time you raised it I asked you for a better word.
If you responded, I didn't see it. So what was your suggestion,
anyway?
>
> > > 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.
>
Yes, but protection suites don't. The real mistake I made on this
issue was using the more generic term "SA bundle" when I should
have said "protection suite" as defined in ISAKMP, and further
compounding it by calling the phase 2 protection suite table
an SA table.
So, the ipsecSaTable should really be called ipsecProtectionSuiteTable.
Is that any better?
==>
Appendix to this mail:
From ISAKMP
Protection Suite: A protection suite is a list of the security services
that must be applied by various security protocols. For example, a pro-
tection suite may consist of DES encryption in IP ESP, and keyed MD5 in IP
AH. All of the protections in a suite must be treated as a single unit.
This is necessary because security services in different security pro-
tocols can have subtle interactions, and the effects of a suite must be
analyzed and verified as a whole.
From ARCH
Case 1. The case of providing end-to-end security between 2 hosts
across the Internet (or an Intranet).
====================================
| |
H1* ------ (Inter/Intranet) ------ H2*
Note that either transport or tunnel mode can be selected by the
hosts. So the headers in a packet between H1 and H2 could look
like any of the following:
Transport Tunnel
----------------- ---------------------
1. [IP1][AH][upper] 4. [IP2][AH][IP1][upper]
2. [IP1][ESP][upper] 5. [IP2][ESP][IP1][upper]
3. [IP1][AH][ESP][upper]
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.