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

Re: Heartbeats Straw Poll

On Mon, 07 Aug 2000, Ricky Charlet wrote:
> Paul Hoffman wrote:
> > When the group was asked "how many people understand this proposal",
> > I saw lots of people who I would have hoped would have raised their
> > hands not doing so (and not voting in the next two questions,
> > thankfully). Sounds like we might want a *short*, concise statement
> > of the problem to the list before the straw poll is taken next. Maybe
> > start with a neutral description of the problem, followed by two
> > paragraphs in favor and two opposed.
> > 
> > --Paul Hoffman, Director
> > --VPN Consortium
> Howdy,
> 	I'll take a stab.
>  	Dead Peer Detection. (or some have called this same concept Black Hole
> Detection).
> 	There are several motives for wanting to be able to detect a dead peer.
> Among these are: 
>  o implementing a redundancy strategy 
>  o ipsra event auditing (required) and accounting (not required) 

This seems to be best reason for a heartbeat protocol.

>  o general resourse/state recovery
> Argument in favor:
> ==================
> 	IPsec creates black holes. If an SA is built among peers SGW1 and
> SSGW2, and later one of those peers (SGW2) becomes unreachable, then
> protected traffic will be black holed from SGW1 into the (now defunct)
> SA with no ICMP unreachable messages being sent back to the sending
> hosts. At the very least, If SGW1 could learn that the SA became a black
> hole, then it would be able to send ICMP unreachables back to the
> sending hosts and the dead peer detection to do that MUST interoperate.

Agree. IMHO, error notification should be part of the base protocol (error
botification, combined with the a 'ping' like mechanism) should be the
way to detect dead peer detection. So for there has been no agreement on
secure dead-peer-detection - inventing a heartbeat protocol for this purpose
seems an overkill.

> But, more sophisticated implementations could also choose to create a
> new SA with a 'back up peer' as one possible redundancy strategy.
> Redundancy stragegies need not interoperate among vendors, but the dead
> peer detection mechanism does need to interoperate.
> 	Also, when a remote access client is builds an SA with an SGW, there is
> an unignorable liklihood that the client may be shut down in non-clean
> fashion (power off, kill process, unplug communications connection...)
> In the abesnce of a dead peer detection mechanism, the SGW would
> continue to believe that the client were present until it initiated a
> re-key event. For gateways connecting thousands of clients, this leads
> to very unattractive leaking of resourses. But more importantly, it
> destroys auditing capabilities. An audit event for client connect and
> client disconnect and loss of client are all deeply significant when you
> are trying to tack who accessed what when for either legal or technical
> reasons. IPSRA requires the capability to track connection start and end
> time (NOTE: in the current rev of the draft draft-ietf-ipsra-reqmts
> these are listed as Accounting requirements in section 2.4. But at the
> IPSRA meeting, the acounting requirements got trimed but connection
> start and stop survived as required audit events).
> Argument Against:
> ==================
> 	Its hard to do. We had trouble with this stuff back when we did TCP.
> Also, IPsec WG has lasted a long time now and needs to close, we have a
> steep prejudice against initiating any new work items.
> -- 
>   Ricky Charlet   : Redcreek Communications   : usa (510) 795-6903
sankar ramamoorthi
email:	sankar@nexsi.com
phone:  408-579-5718 (w)