[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.
-Skip
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: