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

RE: Heartbeats draft available



I knew I would draw flack for putting out a 30 page draft and then claiming
it is simple.

If you want, I can also write a 5 page condensed version which does not
include rationale, diagrams, implementation hints, and optional payloads.

BTW, I didn't mean that putting a new payload inside QM was a kludge. I only
meant that putting a new attribute inside the SA proposal payload was a
kludge.

What you are suggesting is a new configuration protocol (assuming that it
can used for more than negotiating the heartbeat interval). The heartbeat
configuration protocol we define is not tightly bound to ISAKMP-Config, and
it can be ported to other protocols (with a few, generic properties) very
easily.

The reason for not doing this is that it binds the heartbeats to the QM
exchange when they are really a property of the connection.

I could attempt to explain the rationale for decisions such as these in
great detail, but then the draft would be 60 pages instead of 30.

BTW, I am using "connection" to mean the logical connection between two
hosts when at least one SA (either phase 1 or phase 2) exists.

Andrew
--------------------------------------
Beauty with out truth is insubstantial.
Truth without beauty is unbearable.


> -----Original Message-----
> From: Dan Harkins [mailto:dharkins@Network-Alchemy.COM]
> Sent: Wednesday, March 22, 2000 8:43 PM
> To: Andrew Krywaniuk
> Cc: 'Tero Kivinen'; 'Scott G. Kelly'; 'Ricky Charlet';
> ipsec@lists.tislabs.com
> Subject: Re: Heartbeats draft available
>
>
>   The "flat" proposal syntax is not an issue because you can
> negotiate
> the keepalive in phase 2 by just defining a place to hold
> that attribute
> in your already newly defined payload. Just chain it into the
> phase 2 offer:
>
>      hash, SA, KE, newpayload, IDi2, IDr2
>
> where newpayload has a field to hold a standard ISAKMP attribute which
> could be the keepalive interval for the SA(s) created in this
> exchange.
>
>   This is not a kludge, as you suggest, anymore than... well, a lot of
> other proposals for extending IKE.
>
>   I have no religion on whether the term is keepalive or heartbeat or
> whether they belong in phase 1 or phase 2, I'm just pointing out that
> there are lots of ways to do this. And also let me note that,
> just perhaps,
> a protocol that requires 30 pages to describe something as
> simple as "I'm
> still here!" might be a tad heavy.
>
>   How did other people implement their proprietary protocols?
> And how do
> they perform in the field. I know there is deployed code that
> does this
> function. I'd, for one, would like to hear about some real
> world experience
> before we go designing a new protocol.
>
>   Dan.
>
> On Wed, 22 Mar 2000 19:37:05 EST you wrote
> > Hi Scott,
> >
> > What Tero said is correct. Using the SA payload as a
> negotiation protocol
> > for other features is undesirable for many reasons.
> >
> > First, there is the fact that the payload uses a flat
> proposal syntax. This
> > means that the number of proposals in the list is the
> permutation of all the
> > options. Adding even a boolean parameter to the negotiation
> > (heartbeats=yes/no) would double the number of proposals required.
> >
> > As Tero mentioned, we could remove this problem by removing
> the requirement
> > that the SA proposal cannot be modified (thus moving away
> from the flat
> > model), but this has a number of undesirable properties as well.
> >
> > First, it makes IKE even less stateless than it is right now.
> >
> > Also, there is the issue of vendor ids. [EXT-METH] states that
> > implementations MUST NOT send payloads of a private type
> unless both parties
> > have both sent and received a familiar vendor ID. Since the
> SA proposals are
> > sent in the first message of the phase 1 exchange, it seems
> inappropriate to
> > negotiate heartbeats (an experimental protocol) before the
> vendor id has
> > been received.
> >
> > Admittedly, this is not true if you are suggesting that we negotiate
> > heartbeats as part of the QM proposal, but that would bind
> the heartbeat
> > negotiation to the IPsec SA instead of to the connection,
> which is not what
> > we want. That would violate the rule I mentioned in my
> previous message of
> > reducing complexity by stating what you want to do and then
> doing it. (Is
> > this rationale clear? I can go into more detail if it isn't.)
> >
> > Finally, one of the requirements of the draft is to provide
> a flexible
> > negotiation scheme for the heartbeats.
> >
> > I think many people in this WG would agree that the absence of a
> > standardized configuration protocol is hurting IPsec. Right now,
> > ISAKMP-Config is the leading contender for that position,
> which is why I am
> > proposing to use it.
> >
> > I don't see a problem with using ISAKMP-Config; it is
> simple and secure. But
> > if, for whatever reason, the WG is unhappy with
> ISAKMP-Config, then let
> > someone write a draft describing their own configuration
> protocol. If the WG
> > chooses to ratify a different configuration protocol
> instead ISAKMP-Config
> > then we will certainly change the draft to reflect this.
> >
> > Trying to avoid the issue of negotiation by way of a kludge
> like you are
> > suggesting is a false economy. It may seem like a simple
> solution right now,
> > but the sum of many simple, kludgy solutions equals one
> horrendous mess.
> >
> > BTW, I would consider heartbeats to be a feature of the
> connection, and not
> > a feature of the SA. That is why I said that I didn't think
> it was important
> > whether they were sent in phase 1 or phase 2.
> >
> > Andrew
> > --------------------------------------
> > Beauty with out truth is insubstantial.
> > Truth without beauty is unbearable.
> >
> >
> > > -----Original Message-----
> > > From: Tero Kivinen [mailto:kivinen@ssh.fi]
> > > Sent: Tuesday, March 21, 2000 11:16 PM
> > > To: Scott G. Kelly
> > > Cc: Andrew Krywaniuk; 'Ricky Charlet'; ipsec@lists.tislabs.com
> > > Subject: Re: Heartbeats draft available
> > >
> > >
> > > Scott G. Kelly writes:
> > > > Whether "heartbeats" are sent in a phase 1 or phase 2
> SA, they are
> > > > essentially a feature of the SA. Features of SAs are currently
> > > > configured (and negotiated) using SA attributes. Why would
> > > these be any
> > > > different?
> > >
> > > Because SA payloads does not allow responder to modify
> the proposal.
> > > In heartbeat protocol this is almost mandatory feature,
> because the
> > > responder is the one who is going to send the packets,
> thus he wants
> > > to control the parameters.
> > >
> > > Of course we could say that when using this special heartbeat
> > > negotiation protocol, the responder is allowed to modify
> the SA, but
> > > the SA payload is also little too complicated for very basic
> > > negotiation (all the things about transforms, protocols and
> > > proposals).
> > > --
> > > kivinen@iki.fi                               Work :
> +358-9-4354 3218
> > > SSH Communications Security                  http://www.ssh.fi/
> > > SSH IPSEC Toolkit
> http://www.ssh.fi/ipsec/
> > >
> >
>