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

Re: Heartbeats draft available

Andrew Krywaniuk wrote:
> 
> > 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.


Howdy Andrew,
	You make some decent points and there well said. But I've pondered it a
bit and I would like to advocate for using a much simpler mechanism,
in-band in each phase 2 SA. 

PHASE 2 IN_BAND KEEPALIVE PROPOSAL:
	The mechanism is ping. The configuration requirements are that you
allow one IP address each from your tunnel endpoint security gateways in
among your endpoint lists so that the ping is protected by your phase2
SA. You will have to suffer the keepalive traffic in your statistics be
they used for monitoring and/or accounting.  As long as your SA is not
otherwise receiving traffic, ping the peer gateway address once per
configurable period X. After Y successive non-responses, mark the state
of your SA as 'down'. Keep trying the pings and after Y successive good
responses, mark the state as 'up'. Done. ( This idea is so simple that I
do not claim authorship, I'm sure it came up on the list before. )

	If the working group so feels, we could radify several
heartbeat/keepalive mechanisms. In that case Andrew's/Tero's and my
proposals are not competative. But if we think that is unweildy, or we
are just too lazy and we only want one recommended keepalive mechanism,
then choose your side or make up a new one and say your piece.



-- 
  Ricky Charlet   : Redcreek Communications   : usa (510) 795-6903
Follow-Ups: References: