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

Re: Heartbeats Straw Poll


Scaling is an issue, and we are working on some ideas. We need a
standards based one, and I know that we are committed towards that. I am
interested in other vendors who have ideas in this area, but it sounds
like Nortel has a wide ranging patent on this. Does anyone know what
this patent is and the number?

Scott

Dan Harkins wrote:
> 
>   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
References: