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

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/
> >
>
References: