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

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



---
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 2:58 PM
> To: Tim Jenkins
> Cc: ipsec@tis.com
> Subject: Re: FW: IPSec Monitoring MIB works for IPv4 only?
> 
> 
> Tim Jenkins wrote:
> > > 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?
> 
> Let's nip this in the bud: This isn't a snipe, it's an honest 
> question.
> I was at the meeting where you volunteered to produce this draft. I
> didn't hear any such 'mandate' iterated. Hence, my question 
> stands: who
> mandated it? 
>  

If you wanted to know who mandated speed, it was stated by Robert Moskowitz
at meetings at the Chicago IETF. The purpose was to get either a) a
monitoring
only MIB or b) a monitoring only MIB that provided a base for further MIB
work.

I got the impression that it was felt important that the existence of a
monitoring MIB would help IPSec move to the standards stage. I don't know
if that's correct or not.

Your comment appears to attack the design. In my opinion, the design is a
good one based on the assumptions. If you think the assumptions are wrong,
discuss them.

The intent of simplification is two fold: 1) it reduces ambiguity, and 2)
it should make implementation easier for the greatest number of
applications.
If there are applications for which the MIB isn't sufficient, often
augmentation
can be used. We've already seen how some implementations want to tie the
phase 2 virtual tunnels to the tunnel MIB; a number of methods were
suggested.

> <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.
> 
> No, the architecture document simply does not require support for any
> constructs which choose to apply AH first (for whatever 
> reason). I agree
> that the arch doc is right not to require these, but think 
> it's wrong to
> make design decisions which preclude them.
> 
> Further, the isakmp text you quote below doesn't substantiate your
> point. The 'protection suites' it refers to are within a 
> given protocol,
> e.g. for ESP the protection suite might be 3DES, HMAC-SHA1. Your
> argument seems to be that AH and ESP are bundled together in one
> protection suite. Have I misinterpreted your argument?
> 

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.
The SA Payload was omitted for space reasons.  The first protection suite
is presented with one transform for the first protocol and one transform
for the second protocol.  The second protection suite is presented with
two transforms for a single protocol.  An example for this proposal might
be:  Proposal 1 with Protocol 1 as AH with Transform 1 as MD5 AND Protocol
2 as ESP with Transform 1 as 3DES. This is followed by Proposal 2 with
Protocol 1 as ESP with Transform 1 as DES and Transform 2 as 3DES. The
responder MUST select from the two different proposals.  If the second
Proposal is selected, the responder MUST select from the two transforms
for ESP. The resulting protection suite will be either (1) MD5 AND 3DES OR
the selection between (2) DES OR (3) 3DES.
<end quote>

It quite clearly describes the first protection suite offered as having
two protocols. By extension, IPCOMP is a possible third protocol that
may be offered.

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

> 
> > 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.)
> 
> I think your unspoken assumption here is that all ISAKMP sessions
> originate and terminate within the same process on each gateway/host.
> That's not necessarily true. Further, even if the ISAKMP processes are
> the same, I may want ID PFS for the new SA, so it MUST be 
> independent of
> the existing one. Must I tear down the existing one, 
> negotiate a new one
> for PFS, tear that down, and then renegotiate another (non-PFS) SA?
> 

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

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

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

> > > > 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.
> 
> See comments above regarding distinctions between protection 
> suites and
> SA bundles.

See my comments above and the text from ISAKMP.

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.
Follow-Ups: