Re: Deletion of SA
Bill Sommerfeld <sommerfeld@orchard.arlington.ma.us> Mon, 23 March 1998 17:10 UTC
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA23865 for ipsec-outgoing; Mon, 23 Mar 1998 12:10:14 -0500 (EST)
Message-Id: <199803231722.RAA06346@orchard.arlington.ma.us>
To: Michael Richardson <mcr@sandelman.ottawa.on.ca>
cc: ipsec@tis.com
Subject: Re: Deletion of SA
In-reply-to: Your message of "Mon, 23 Mar 1998 10:07:33 -0500 ." <199803231507.KAA00292@morden.sandelman.ottawa.on.ca>
Date: Mon, 23 Mar 1998 12:22:32 -0500
From: Bill Sommerfeld <sommerfeld@orchard.arlington.ma.us>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
> 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..
- Deletion of SA K SrinivasRao
- Re: Deletion of SA Michael Richardson
- Re: Deletion of SA Daniel Harkins
- Re: Deletion of SA Bill Sommerfeld
- Re: Deletion of SA Scott G. Kelly
- Re: Deletion of SA Scott G. Kelly
- Re: Deletion of SA K SrinivasRao
- Re: Deletion of SA K SrinivasRao
- Re: Deletion of SA Scott G. Kelly
- Re: Deletion of SA S. B. Kulkarni
- Re: Deletion of SA Scott G. Kelly
- (administrivia) About my archives Michael C. Richardson
- Re: Deletion of SA S. B. Kulkarni