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

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

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

You're being pretty snippy here, Tim. Relax. This is not a battle, this
is a constructive discussion. Your view may prevail, or you may come
away with a new view. Either way, we're trying to get the best possible
design.

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

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

I think you need to give this more thought, but let's not waste time on
semantics.

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

No, you didn't ask for a better word. Here's the excerpt from that
exchange:

I said: 
> > 3) sec 4.1, "IPSec Virtual Tunnels", line 1: "IPSec implementations 
> > effectively create tunnels..." - the use of 'tunnels' here is quite 
> > confusing. We have tunnel-mode SAs and transport-mode SAs. Are you 
> > including both here? If so, perhaps a better term could be chosen. 

and you replied:
> I will elaborate on the concepts of virtual tunnels created by SAs. It > should deal with a lot of the confusion associated
> with our over-loaded use of the word 'tunnel'.

Nonetheless, I'll give this some thought and see if I can come up with a
better conceptualization.

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

-----

I am not sitting here taking shots at you, Tim. I'm an implementer, just
like you, and I want the best possible design to come out of this
effort. I'm sorry if I've come across as being hostile or obnoxious in
any way - it certainly is not intended.

Scott
Follow-Ups: References: