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

Re: Heartbeats Straw Poll

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) 
 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.
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
Follow-Ups: References: