[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SA Recovery (was RE: issues from the bakeoff)
Thanks Tim,
I agree that active keep-alive will solve the problem, but it will take some
time to agree on the standard for that.
In the interim I was trying to stimulate discussion on the use of usually long
series of INVALID_SPI messages from the re-booted node, which are unfortunately
unprotected, but may contain some "clue" of their authenticity.
Tim Jenkins wrote:
> Slava,
>
> In the absence of keep-alives, this procedure can be used to allow recovery
> after one entity has died and recover.
>
> Basically, the recovered entity will receive encrypted traffic from a peer
> with SPI values that it doesn't understand. The assumption is that the peer
> had valid SAs with it that it lost when it died.
>
> In order to tell the peer that the SA (and any others it may think it had
> with it) are invalid is to set up a phase 1 SA with it that includes the
> initial contact notification. Receipt of the initial contact notification
> should cause the peer sending the packets with invalid SPIs to clear all its
> SAs and re-establish new ones.
>
> A similar approach can be used if an entity receives phase 1 packets with
> invalid cookies.
>
> The problems with this approach are:
> 1) Need main mode to authenticate initial contact (unless use of the
> encrypted aggressive mode three message with initial contact is okay, but
> that's currently prohibited.)
> 2) There may be no specific knowledge of the peer that's sending the invalid
> SPIs by the entity that's recovered, so initiating back presents a form of
> DOS attack if the SPI-sending peer is an attacker that is intentionally
> sending packets with bogus SPI values.
>
> That's why there is a need for SA management while the SAs are up, so that
> crash recovery can be active, rather than reactive.
>
> Tim
>
> ---
> Tim Jenkins TimeStep Corporation
> tjenkins@timestep.com http://www.timestep.com
> (613) 599-3610 x4304 Fax: (613) 599-3617
>
> > -----Original Message-----
> > From: Slava Kavsan [mailto:bkavsan@ire-ma.com]
> > Sent: June 16, 1999 9:34 AM
> > To: Dan Harkins
> > Cc: ipsec@lists.tislabs.com
> > Subject: Re: issues from the bakeoff
> >
> >
> > Dan Harkins wrote:
> >
> > >
> > > It was suggested that a keepalive mechanism be
> > built into IKE. Several people
> > > already have proprietary keepalive mechanisms in
> > their implementations.
> > > Perhaps the person(s) who brought this up will
> > write up a draft specifying
> > > how this is to be done.
> >
> > It may take some time to write and agree to such draft. Could
> > we meanwhile design some simple
> > (which may not be 100% bullet-proff) logic around
> > unprotected INVALID_SPI notifications that
> > rebooted node most likely to send to another party which is
> > unaware of the re-booted partner
> > and keep sending encrypted traffic to it?
> >
> >
> > --
> > Bronislav Kavsan
> > IRE Secure Solutions, Inc.
> > 100 Conifer Hill Drive Suite 513
> > Danvers, MA 01923
> > voice: 978-739-2384
> > http://www.ire.com
> >
> >
> >
--
Bronislav Kavsan
IRE Secure Solutions, Inc.
100 Conifer Hill Drive Suite 513
Danvers, MA 01923
voice: 978-739-2384
http://www.ire.com
Follow-Ups:
References: