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

Re: Heartbeats Straw Poll

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: