[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Heartbeats Straw Poll (part 3)
Part 3: conclusions
I might ask where some of these comments were during the last two
discussions on this topic, but it goes to show what I've said before, which
is that you can't always get people to do a good requirements analysis until
you propose something specific.
The Isakmp Heartbeat Protocol provides a comprehensive solution to the
problem I'm as I've described it (see message "RE: Heartbeats Straw Poll
(part 1)"). By themselves, none of the alternate suggestions I've seen here
provide a comprehensive solution.
Could we in fact construct a different comprehensive solution from the ideas
we've been discussing, without requiring regular heartbeats. Yes, I think
so:
- Require continuous channel mode.
- Require that deletes are sent using the acknowledged informational
exchange.
- In the absence of traffic, send regular clear pings to test the
availability of the route.
- If the route goes down, keep the SAs up for 'awhile'. If the route comes
back up before you delete the phase 1, use a phase 1 ping (with a few
retries) to see if the peer is still there. If that succeeds, then send a
SPI list to resynchronize the phase 2s.
- Use a birth certificate to recover from atomic failures.
- Require that redundant clusters share key material *OR* at the very least
share SPIs and cookies so these can't be spoofed after a failure.
This is a comprehensive solution to the problem I've described. I don't
think this solution will have the same predictable-recovery properties of
the Isakmp Heartbeat protocol, but it's not bad. Of course it requires
changes to IKE, but these changes fall within the spirit of making IKE
simpler.
Andrew
--------------------------------------
Beauty with out truth is insubstantial.
Truth without beauty is unbearable.
References: