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

Re: Heartbeats Straw Poll


>>>>> "Derek" == Derek Atkins <warlord@mit.edu> 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>
 Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html
	mailto:mcr@sandelman.ottawa.on.ca	mailto:mcr@solidum.com
Follow-Ups: References: