[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)
References: