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

Re: Heartbeats (was RE: keepalives)



Andrew Krywaniuk wrote:
<trimmed...>
> >       But I also disagree with the idea that the goal of our
> > heartbeat is for
> > IKE's benefit alone. This discussion certianly started because we were
> > debating IKE continous move Vs. dangeling implementations and IKE
> > heartbeats were originally suggested as a way to help us clean up IKE
> > state more confidently when we can know that a peer is nolonger
> > responsive.
> 
> I disagree. I think this discussion started because we need heartbeats for
> ipsra. The fact that the same issue came up in the dangling SA thread was a
> 'triggered coincidence'.

This issue touches remote access, but that is not the extent of it. I
have no idea what a triggered coincidence is (other than an oxymoron),
but the fact is that this issue is being discussed on the general ipsec
list, not the ipsra list, and there is a reason for that.

> > But others have mentioned, and I agree, that heartbeat or
> > dead-peer-detection should serve other purposes as well and
> > among these
> > are fail-over action triggering, and alert generation. This is not to
> > say that dead-peer-detection cannot be within IKE. I am just trying to
> > get the list to consider that we do have more options and
> > should examine
> > them.
> 
> I think these are orthagonal issues. The first step will always be
> detection, but dead peer detection is useless if you don't do anything about
> it. After you detect the dead peer you have to have a response, which may be
> an alert, an attempt to reconnect, or a fail-over protocol.
> 

I think you mean "orthogonal", and "independent" would perhaps be more
forthright, even if it is still wrong. We want to detect the fact that a
peer is no longer there for the express purpose of taking some action -
these are hardly unrelated, independent, or orthogonal. 

I introduced the term "dead peer detection" into this discussion
originally because I believe that this is a dimension of the discussion
that was being neglected. There are (at least) 2 ways to look at this:
in one, we expect the remote peer to actively announce that it is still
alive; in another, we detect that the remote peer is no longer present
using various cues which we have yet to discuss. 

There seem to be a few issues here: first, there seems to be a
requirement that we detect when we are black-holing packets. Second,
there seems to be a requirement for detecting when a remote access
client terminates a session in order to facilitate accounting. These are
closely related, and not unique to the remote access scenario.

Does anyone have additional requirements we are trying to satisfy?

Scott


References: