[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Heartbeats (was RE: keepalives)
I've been looking into this privately, as I'm sure a lot of people must
have.
We wanted a heartbeat functions as much for resilience as much as tidying up
resource - you can't fall back to a secondary GW until you detect that the
primary GW has failed.
We also want to time out unused connections, so the heartbeat shouldn't
interfere with this function. A naive heartbeat implementation could keep
an SA rekeying indefinitely.
Somewhat related to the last question is dial-up. If the GW is sitting on
the other side of an, eg, ISDN link the heartbeat shouldn't keep up the link
indefinitely. This shouldn't be such an issue for permanent links - the
overhead of the heartbeat should be minimal. I think there will need to be
different behaviour for permanent and dial-up links.
The purpose of the heartbeat should be to determine that the peer is still
active and communicating. This can be deduced as long as you continue to
receive authenticated traffic from the peer. I think this means that
heartbeats are not required as long as regular IPSEC protected traffic is
being received from the peer. In the absence of regular traffic to a peer,
heartbeats should be transmitted at regular configurable intervals. In
these circumstances a connection can be considered dead if no traffic is
received within a configurable interval.
I'm not sure what heartbeat packet is best, ISAKMP, transport ESP or
'hijacked' tunnelled ESP. I think this is a new protocol but I don't think
it justifies an SA of its own. I think using an ISAKMP notification is best
as most people seem to want this associated with the phase 1 SA.
The ISDN scenario is rather harder to crack. My thoughts on this are if the
customer really doesn't want his line brought up for crypto-management then
the keep-alive mechanism should function just briefly after regular traffic
is transmitted.
Chris
Follow-Ups: