[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: SA Recovery (was RE: issues from the bakeoff)
Yes, that's what I was suggesting.
Thanks, Steve.
-----Original Message-----
From: John E. Horton [mailto:jehorton@erols.com]
Sent: Thursday, June 17, 1999 6:57 PM
To: Waters, Stephen; Tim Jenkins
Cc:
Subject: RE: SA Recovery (was RE: issues from the bakeoff)
Stephen -
Clear traffic ICMP messages generated by a client on a LAN behind a FW
blocking ICMP will cause a problem for this proposal.
IPSEC Encapsulated ICMPs to the gateway would work.
Regards,
John Horton
At 06:19 PM 6/17/99 +0100, Waters, Stephen wrote:
>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
>>
>>
>>