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

RE: Heartbeats draft (fwd)

If the problem we are trying to solve is high availability (the Heartbeats
draft doesn't address this anyway), there are many ways to solve it. We
don't have to start with the premise that keepalives are absolutely
necessary, and then apply the keepalives solution to all the problems.

-chinna

On Wed, 29 Mar 2000, Chris Trobridge wrote:

> The problem to solve is to detect when a peer has gone down so that some
> action can be taken.  This action may something other than renegotiating
> with the same peer - it might mean just deleting the SA or it may mean
> finding an alternative gateway.  This latter case is important in the
> provision of high availability networks and cannot be solved by the peer
> renegotiating when it comes back up.  The peer might not actually be the
> equipment at fault or it might be 'lost' permanently.
> 
> Obviously not every network needs this so it's something that should be
> configurable (and optional).  Heartbeats should only be requested when
> required and it should be possible for an implmentation to control the
> quantity of heartbeats it generates and to which peers.
> 
> I'd still like there to be the option of a phase 1 heartbeat which is only
> sent in the absence of traffic on any connected phase 2 SAs.  This will
> cover a wide range of situations and means that no heartbeat traffic is
> generated while the associated SAs are in active use.  This would reduce the
> benefit of the active SA listing and I think that should be optional too.
> 
> Chris
> 
> > -----Original Message-----
> > From: CHINNA N.R. PELLACURU [mailto:pcn@cisco.com]
> > Sent: 29 March 2000 06:13
> > To: Jan Vilhuber
> > Cc: Henry Spencer; IP Security List
> > Subject: Re: Heartbeats draft (fwd)
> > 
> 
> <snip>
> 
> > If you look at the two proposals for solving the problem of 
> > syncing peers
> > when one of them goes down (which I think is a fairly corner case):
> > heartbeats/no heartbeats. 
> > 
> > Heartbeats solution is chatty, and it sucks up a lot of processing and
> > bandwidth, but it doesn't have any DOS considerations. And the major
> > disadvantage is that it is not very acceptable in dialer 
> > scenarios, which
> > represent a major portion of our deployment base for IPSec.
> > 
> > No heartbeats solution has some DOS considerations, that I 
> > feel are EASY
> > to tackle. Advantages are it can be used in dial environments, and not
> > bandwidth/processing intensive.
> > 
> > So, I feel that we should tackle the DOS issues here, instead 
> > of imposing
> > an un-ending DOS attack on ourselves by doing Heartbeats, 
> > once every 20
> > seconds (the recommended heartbeat interval) to all the peers 
> > in the world
> > that we know of. This doesn't scale. I would rather prefer to 
> > tackle the
> > DOS issues, and save processing and bandwidth for sending 
> > real traffic.
> > 
> > > 
> > > Just because there's issues with cookies doesn't mean we 
> > should add yet
> > > ANOTHER way that IKE can be taken down via DOS (bounded.. 
> > yes yes...).
> > > 
> > 
> > For any protocol, bad implementations can be brought down, and that
> > doesn't mean that it is a failure of the protocol. I guess it 
> > is pretty
> > sraight forward to avoid any DOS vulnerablity in this case, and if the
> > implementation chooses to be dumb about it, then I guess it is the
> > implementation's problem, and not a protocol problem.
> > 
> > > Also, we're not creating an, as you put it, 'chatty 
> > protocol', JUST to save
> > > ourselves from DOS stuff. We're creating this protocol to 
> > do keepalives which
> > > serve a useful purpose, besides DOS stuff.
> > > 
> > 
> > The problem that the heartbeats are trying to solve, can be 
> > solved even
> > without them. If you have any specific scenario where 
> > heartbeats are the
> > only solution to the problem, please post it.
> > 
> > -chinna
> 
> 

chinna narasimha reddy pellacuru
s/w engineer
Follow-Ups: References: