Stale SAs

Bronislav Kavsan <bkavsan@ire-ma.com> Fri, 20 February 1998 13:35 UTC

Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA17607 for ipsec-outgoing; Fri, 20 Feb 1998 08:35:56 -0500 (EST)
Message-ID: <34ED8841.DC40CE0B@ire-ma.com>
Date: Fri, 20 Feb 1998 08:42:25 -0500
From: Bronislav Kavsan <bkavsan@ire-ma.com>
X-Mailer: Mozilla 4.03 [en] (WinNT; U)
MIME-Version: 1.0
To: "ipsec@tis.com" <ipsec@tis.com>
Subject: Stale SAs
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-MDaemon-Deliver-To: ipsec@tis.com
Sender: owner-ipsec@ex.tis.com
Precedence: bulk

I couldn't find anyhting of the "MUST" nature in the IKE protocol (and
Dan Harkins confirmed), which could mandate remote IPsec host/SGW to
assist my host to discover stale SA. This situation may arise when the
remote host/SGW reboots and starts a new IPsec life, while my host has
an SA from the previous engagement with this host/SGW.

Another complicating factor in this scenario could be the fact that my
host is a road warrier and the remote host/SGW has non-IP Address-based
entry for me or my road warrier  in his policy - therefore it cannot use
the IP address to figure out from whom these AH/ESP packets are coming
from.

What are the alternatives for solving this situation? Should we push the
problem to the IPsecond and keep our SAs stale till then :), or to have
some kind of "gentlemen's" agreement to send an nformational message in
this case (though their arrival is not guranteed), or initiate new IKE
proposal to the guy hopelessly trying to send these IPsec packets,
or..........

Any ideas on how to solve this problem locally, without assistance from
the other side? (SA timeouts? Inactivity timeouts?)

Thank you,

Slava Kavsan
IRE