Re: Deletion of SA

K SrinivasRao <srinu@trinc.com> Tue, 24 March 1998 12:25 UTC

Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA02004 for ipsec-outgoing; Tue, 24 Mar 1998 07:25:22 -0500 (EST)
Message-Id: <3.0.1.32.19980324172015.006c65cc@192.9.200.10>
X-Sender: srinu@192.9.200.10
X-Mailer: Windows Eudora Light Version 3.0.1 (32)
Date: Tue, 24 Mar 1998 17:20:15 +0500
To: Bill Sommerfeld <sommerfeld@orchard.arlington.ma.us>
From: K SrinivasRao <srinu@trinc.com>
Subject: Re: Deletion of SA
Cc: ipsec@tis.com
In-Reply-To: <199803231722.RAA06346@orchard.arlington.ma.us>
References: <Your message of "Mon, 23 Mar 1998 10:07:33 -0500 ." <199803231507.KAA00292@morden.sandelman.ottawa.on.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk

At 12:22 PM 3/23/98 -0500, Bill Sommerfeld wrote:
>>     K> negotiated a new SA and will use that for future
>>     K> communications. Should H1 send a delete payload to delete H2's
>> 
>>   Yes. That should occur as part of the new SA being setup.
>>   A question though: is a "delete" too strong here? Perhaps a "please
>> delete this SA in X seconds" would be more appropriate? As a notify
>> perhaps? That would allow SA's to be negotiated in advance of being
>> used, and it also allows the network to drain.
>>   Someone tell me that this is already addressed, but I just missed
>> that part :-)
>
>Alternatively, you could put the burden of not sending the delete
>until the *sender* has reason to believe that all relevant traffic has
>drained from the net...
>

>For instance, in the case of per-connection keying, the sender could
>send a delete once the connection closed..

In the case of per-connection keying, the connection is closed only when
the application stops running. But here the case is different. The
application has still packets to send, but the SA has run out of
bytes(Note: we considered the case when SA has life time in byte counts)
and has to be renegotiated. Hence the H1(sender) can't wait till the
connection closes for sending a delete payload to H2. 
SrinivasRao. B. Kulkarni                             
Rendezvous On Chip Pvt Ltd.
First Floor, Plot No. 14,
NewVasaviNagar, Kharkhana,
SECUNDERABAD - 500019.
Ph : (040)7742606
email address : srinu@trinc.com