On Jan 25, 2010, at 1:44 PM, Tero Kivinen wrote: > Yoav Nir writes: > >> Issue #141 - Silently deleting the Child SA after a CHILD_SA_NOT_FOUND >> ====================================================================== >> Section 2.25: "A peer that receives a CHILD_SA_NOT_FOUND >> notification SHOULD silently delete the Child SA": Is this really >> necessary? I think this notification should only occur in cases where >> DELETE payload for this Child SA pair has already been sent, and >> probably has been processed already by the time the CHILD_SA_NOT_FOUND >> notification is received. >> >> No responses were received for this. > > I proposed new text for this: > > http://www.ietf.org/mail-archive/web/ipsec/current/msg05695.html > >> My opinion is that CHILD_SA_NOT_FOUND will usually not occur at all. >> Even if lifetime is the same on both peers, rekeying is always done >> earlier than deleting (for example, if your SAs last 1 hour, you >> might rekey at 58 minutes, but only delete after 60 minmutes), so >> collisions of rekey and delete will be rare. Because of this, I >> believe that the CHILD_SA_NOT_FOUND will stem from some mismatch in >> the SAD between the two peers. Yes, this probably indicates a bug >> somewhere, but these things do happen. I believe the text should >> stay, as it clarifies that the peer does not need to create a new >> INFORMATIONAL exchange with a DELETE payload to discard. In fact the >> text already has in brackets "(if it still exists)" > > That bracketed part was added to solve this #141. > >> If anyone else has comments about this issue, please raise them NOW, >> because we are going to close this in a few days. > > So I think this issue can already be closed, as the at least from my > point of view the fix has already been added to the -07 version.
Thanks. Closed. _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
