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

Re: Heartbeats Straw Poll

I would add a third reason for heartbeats/keepalives.  To be able to do accurate
accounting the SG needs to know within a reasonable time that the client has
disconnected.  If the interface to the AAA server is through IKE and not some
other protocol, than IKE must have a mechanism for detecting a lost peer.  This
issue has been raised on several occasions on the IPSRA list.


On Fri, 4 Aug 2000, Bill Sommerfeld wrote:

> As several people brought up in the meeting, "keepalives" under the
> wrong circumstances tend to turn into "make-deads".  IKE and IPSEC
> implementations should not delete SA's prior to their normal
> expiration merely because they haven't heard from the other end in a
> while.
> There appear to be two different properties people are looking for
> from heartbeats/keepalives:
> First, rapid recovery from loss of state on one end of a security
> association (due to power loss/reboot/reset), so a new IKE SA can be
> initiated on one end or the other.  Once this happens, the half-dead
> state on one end can be garbage collected as a result of an
> affirmative indication (IKE INITIAL-CONTACT) that the other side lost
> state.
> Second, detection of loss of connectivity between two security
> gateways so that traffic can be rerouted through an alternate gateway.
> This is really a dynamic routing problem and could (and probably
> should) be done without prematurely tearing down IKE SA's and IPSEC
> SA's which may still exist and may still be useful once the
> connectivity comes back.
> It's not clear that the same protocol feature can/should provide both
> of these properties..
> 						- Bill

Follow-Ups: References: