[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
SA Recovery (was RE: issues from the bakeoff)
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
>
>
>
Follow-Ups: