[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Heartbeats draft available
> While I
> readily agree
> that a simple tallying of the posts shows a majority arguing
> in favor of
> doing heartbeats in ISAKMP, could you please spend a little
> time anyway
> going over your justifications for this approach above the others.
Hi Ricky,
Let me first state that the draft specifies two things:
a) A framework for negotiating and implementing heartbeats.
b) A default mode of operation that has been chosen for interoperability.
If you want to define some other mode of operation for use with your own
products (e.g. phase 2 heartbeats), the framework lets you do this. Just
define a new heartbeat type from the private range, exchange vendor ids, and
you're set. Consenting parties can replace any of the 3 layers we describe
in the draft.
But as for part b, let's face it... When you're defining a standard
interoperability mode, vendor support DOES matter, and the majority of
support was for a phase 1 approach.
Even when I talked to some of the vendors who do "dangle" phase 1 SAs, many
of them were still in favour of using phase 1 heartbeats. Most vendors who
dangle SAs say they do so only when they are low on memory, so they will
still be able to use heartbeats most of the time.
We also wanted the default mode to be easy to understand and easy to
implement. With the heartbeat protocol, you can implement the bare minimum
set of requirements and still be guaranteed of interoperability with the
peer.
Phase 2 heartbeats do have a number of advantages over phase 1 heartbeats,
but there are also a lot of added complications, which would make it
difficult to define a simple phase 2 heartbeat mode that is suitable for
interoperability.
Some of the complications: using hijacked SAs (mixing customer traffic with
management traffic -- our customers don't like this), interactions with the
accounting service (requires two traffic counters), need for a policy hole
to allow the heartbeat traffic, negotiation of which exact SA parameters to
use, flexibility of packet format, potential of defeating the peer's
inactivity timeout mechanism.
Allowing all of the common scenarios that various vendors want to support
would require a much more elaborate negotiation scheme. And it doesn't seem
fair to legislate all or most of the above behaviours. Which is why you are
free to define your own protocol for private use, at which point you can
make whatever assumptions you want about the peer's configuration.
It's impossible to please everybody. But all things considered, I would
rather have a heartbeat protocol that has to be turned off under low memory
conditions than a protocol that causes interoperability nightmares because
it is too difficult to negotiate.
Andrew
_______________________________________________
Beauty without truth is insubstantial.
Truth without beauty is unbearable.
Follow-Ups:
References: