Hi Martin, On Thursday 28 June 2012 01:27 PM, Martin Willi wrote: > Hi, > >> 10[IKE] received NO_PROPOSAL_CHOSEN notify, no CHILD_SA built >> 10[IKE] CHILD_SA rekeying failed, trying again in 24 seconds >> Hence, is sending notify payload (no proposal chosen) not treated as >> failure for rekey attempt? > NO_PROPOSAL_CHOSEN usually indicates a permanent error, yes, but there > are corner cases where a retry makes sense. > > RFC 5996 defines a TEMPORARY_FAILURE to indicate that rekeying is > currently not possible (most likely because of an exchange collision), > and the peer should try again. Before RFC 5996, there was no such > specific notify, and NO_PROPOSAL_CHOSEN was used. > > We ourself still use a NO_PROPOSAL_CHOSEN notify in some of these > situations. I think we should update to the new RFC 5996 notifies, but > we haven't done this yet. >
Yes, it is better explained in RFC 5996. So, any suggestion that if I should raise a bug to improve this error handling in strongswan ? >> "If an SA has expired or is about to expire and rekeying attempts >> using the mechanisms described here fail, an implementation MUST close >> the IKE_SA and any associated CHILD_SAs and then MAY start new ones." > Another reason for retrying is that the responder might have updated the > configuration (for example, due to manual intervention). The hard SA > lifetime still applies, and the SA gets deleted once expired. So I think > we are fine with the above paragraph. > Agree. Thanks for the very useful reference you shared, Gowri Shankar > Regards > Martin > > _______________________________________________ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users