[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Heartbeats Straw Poll
>>>>> "Derek" == Derek Atkins <firstname.lastname@example.org> writes:
Derek> The problem with dead-peer detection is that you have no way to
Derek> know how or why a peer lost contact. You don't know if they got
Derek> rebooted, lost power, lost connectivity, or some other reason.
Derek> Perhaps your peer's upstream provider fell off the net? Or maybe
Yes, those are all good arguments for why heartbeats/keep alives/make-deads
should be optional, and why one should be able to turn them off, or why you
might want to have your client refuse to accept to negotiate them.
Derek> If you're really that worried about the resources for "dead" SAs,
Derek> negotiate relatively short rekey times, at which point if your
Derek> peer disappears, the SA will timeout in a relatively short time.
This has a detrimental effect on the live SAs.
Derek> As has been mentioned, 'keep-alives' really equate to 'make-dead'.
Agreed, which why the facility that should be negotiated is called a
"heart beat", not a "keep alive".
Derek> If you want to see if something is still there, why not just keep
Derek> track of the last time a packet has been received on a particular
Derek> SA and just send an ICMP ping_request? The ping_response will
Derek> tell you your peer is alive, and you can update your SA
Derek> time-of-last-packet to the current time. But what's the point of
Derek> that? Short key lifetimes solves this problem.
In my opinion, IPsec heartbeats should just be ICMP ping requests, and the
fact that any traffic is received is the "response". There is really no
negotiation required in this context. Only a phase I heartbeat requires
some kind of negotiation as you have to agree to keep the phase I SA alive.
:!mcr!: | Solidum Systems Corporation, http://www.solidum.com
Michael Richardson |For a better connected world,where data flows faster<tm>