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

Re: Heartbeats Straw Poll

  The only implementation of keepalives that I'm aware of is Cisco's
and it doesn't scale. This was discussed in Adelaide by Chinna 
Narasimha Reddy Pellacuru. That implementation may have problems-- I
wrote it after all-- but a solution to its problems has not been
discussed and both drafts which address keepalives/heartbeats are
essentially what I implemented in IOS: a simple request/response,
"are you there?"/"yes, I'm here". Has Cisco's version been fixed to 
scale? If so, can you explain how so that that information can be 
incorporated into the drafts? If not, then perhaps we should take a 
step back and look at what it is we're doing since we have evidence 
that what is being proposed doesn't work right.

  It's an interesting question about addressing keepalives in the
"IKE rework". But doesn't this change IKE? Come to think of it, aren't
keepalives officially prohibited until the "IKE rework" is finished?

  Dan.

On Mon, 07 Aug 2000 15:55:21 PDT you wrote
> Derek Atkins wrote:
> > 
> > The problem with dead-peer detection is that you have no way to know
> > how or why a peer lost contact.  You don't know if they got rebooted,
> > lost power, lost connectivity, or some other reason.  Perhaps your
> > peer's upstream provider fell off the net?  Or maybe it's a laptop and
> > the laptop got unplugged and moved.  The problem is you can't tell.
> > Worse, in the case of an intermittent lossage, you really don't want
> > to reap the SAs, because the peer might come back.
> 
> I do not really care WHY it is dead. The end result is some clean up of
> the SADB and aMaybe we need a "death certificate" CA :-) Intermittent
> lossage can be solved by having a window of missed "heartbeats". Idle
> timers could also help, but you would need to know the traffic type to
> configure those correctly (kind of a layer violation).
> 
> > 
> > If you're really that worried about the resources for "dead" SAs,
> > negotiate relatively short rekey times, at which point if your peer
> > disappears, the SA will timeout in a relatively short time.
> > 
> > As has been mentioned, 'keep-alives' really equate to 'make-dead'.  If
> > you want to see if something is still there, why not just keep track
> > of the last time a packet has been received on a particular SA and
> > just send an ICMP ping_request?  The ping_response will tell you your
> > peer is alive, and you can update your SA time-of-last-packet to the
> > current time.  But what's the point of that?  Short key lifetimes
> > solves this problem.
> 
> Short Key lifetimes do solve some of the problem, but can be expensive.
> 
> During the IKE rework, maybe some of these issues can be addressed. This
> is quite an interesting problem to solve.
> 
> > 
> > -derek
> > 
> > Scott Fanning <sfanning@cisco.com> writes:
> > 
> > > Bill
> > >
> > > Thats a good idea, but from an implementation point of view, I am not
> > > sure if I like the idea of maintaining a timestamp for every packet (SA
> > > Used) through a tunnel.
> > >
> > > I guess the problem I want to address with the heartbeats is dead-peer
> > > detection, and as a result do action foo. INITIAL-CONTACT does help in
> > > SADB sync'ing but is not authenticated and there is no assured delivery.
> > > I think that Scotts point of auditing is a good side-effect of dead-peer
> > > detection, and could also be tied to accounting, but I agree this is
> > > outside the scope of the problem.
> > >
> > > Scott
> > >
> > >
> > > Bill Sommerfeld wrote:
> > > >
> > > > > Yes, it was pointed out at the ipsra meeting that accounting is not a
> > > > > requirement. However, what about auditing? For purposes of security
> > > > > auditing, it is necessary to know when a remote access client
> > > > > disconnects. Is this a valid requirement?
> > > >
> > > > Wouldn't keeping track of the last time an SA was used, and logging it
> > > > into your audit trail when the SA expires or is deleted, be sufficient
> > > > for auditing purposes?
> > > >
> > > >                                         - Bill
> > 
> > --
> >        Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
> >        Member, MIT Student Information Processing Board  (SIPB)
> >        URL: http://web.mit.edu/warlord/      PP-ASEL      N1NWH
> >        warlord@MIT.EDU                        PGP key available
Follow-Ups: References: