[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: SA Recovery (was RE: issues from the bakeoff)
Hi,
A quick proposal for tunnel keep-alive:
The client pings the Security Gateway on a configurable timer once the
IPSEC-SA is connected. The policy should allow responses to protected pings
terminating at the security gateway.
A counter of missed echo-replies since the last echo-rely is kept which is
reset to zero whenever a reply is received.
A configurable miss-replies threshold is used to determine when the SA is
'dead'. When the SA dies, the client deletes the outgoing SA and inbound SA
and restarts at Phase1 with the remote security gateway. If the security
gateway remains 'unreachable' (more timers and thresholds), the client can
try other security gateways.
How does that sound? For remote access, I am only really interested in the
client detecting that the security gateway has become unreachable. For
LAN-LAN, this mechanism can be used symmetrically.
In time, it may be possible to define formatted data in the ping payload to
allow SLA/QOS info to be exchange between tunnel peers. Since ping data is
meaningless to non-participating remote system, this will be treated just
like any other ping.
Cheers, Steve.
-----Original Message-----
From: Tim Jenkins [mailto:tjenkins@TimeStep.com]
Sent: Thursday, June 17, 1999 3:19 PM
To: Slava Kavsan
Cc: ipsec@lists.tislabs.com
Subject: 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: