[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Deletion of SA
Hi Scott,
(May be you are already aware of this)
The other day when was re-reading the draft I found that the draft is
clear. It says if H1 has SA(s) with H2 and deleted it's inbound SA(s) it
sends a delete payload with it's inbound SA(s) SPI to H2. The H2 on
receiving delete payload from H1 associates the source address from the
packet with SPI(s) and protocol-Id to delete it's outbound SA with H2.
Because the draft says the SPI sent in the delete payload is the sending
entity's SPI (Refer to the following paragraph from the draft).
********************************************************************
>From draft-ietf-ipsec-isakmp-10.txt, July 3, 1998
3.15 Delete Payload
<trimmed...>
Deletion which is concerned with a Protocol SA, such as ESP or AH, will
contain the Protocol-Id of that protocol (e.g. ESP, AH)and the SPI is the
sending entity's SPI(s).
*********************************************************************
But infact I agree with you that H1 MAY send a Notification Payload to H2
after deleting his outbound SA and delete payload to H2 after deleting his
inbound SA. But the problem arises finding the corresponding inbound SA
when you delete any outbound SA at H1. One possibility is to reverse the SA
selectors and serach.
But will it work for all the cases ?
Thank U
- Srinu
At 09:45 AM 9/2/98 -0700, Scott G. Kelly wrote:
>S. B. Kulkarni wrote:
>>
>> Hi Scott,
>>
>> I remember you raised the following question in response to my question
>> regarding SA deletion. But there was no further discussion on this issue.
>> The issue was that, which SA to be deleted when you receive the delete
>> payload with multiple SPI.
>>
>
><trimmed...>
>
>Right. For the entire thread, see
>
>http://www.sandelman.ottawa.on.ca/ipsec/1998/03/msg00235.html
>
>and follow the thread-next links.
>
>The issue was never resolved, although as a practical matter we decided
>(for our products) that you may only delete the incoming SA, and may
>send the notify for the outgoing SA as a courtesy.
>
>This dances around a much larger problem, one which is at the root of
>several other blossoming issues, not the least is which is the so-called
>'rekey collision' problem, where both sides timeout the SA at the same
>time and collide while trying to rekey.
>
>This larger problem has to do with the semantic definition of the SA vs.
>the actual operational definition as we have implemented it. SA's are,
>by definition, unidirectional constructs. As a matter of convenience,
>this directional distinction has been blurred and SAs have been linked
>into inbound-outbound pairs in our current implementations. This
>simplifies parameter negotiation in that we can negotiate a symmetric SA
>pair with one exchange group, reducing the overhead associated with SA
>instantiation.
>
>On the other hand, this has several drawbacks, not the least of which
>are the behavioral ambiguities related to deleting SAs and rekeying.
>This is an issue which requires thoughtful exploration. While the
>convenience realized from 'bidirectionalizing' the SAs is substantial
>(and therefore perhaps justifiable), the ramifications have not been
>fully considered.
>
>I believe this issue is on the agenda for ipsecond. If you have
>suggestions for resolution, please post them.
>
>
******************************************************************
* OFFICE ADDRESS : *
* SrinivasRao. B. Kulkarni *
* Rendezvous On Chip Pvt Ltd. *
* First Floor, Plot No. 14, *
* NewVasaviNagar, Kharkhana, *
* SECUNDERABAD - 500015. *
* STATE ANDHRA PRADESH *
* INDIA *
* Ph : (040) 7742606, 7740406 *
* email address : srinu@trinc.com *
******************************************************************
References: