-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Nico Williams Sent: Saturday, January 21, 2012 2:19 AM To: Prashant Batra (prbatra) Cc: [email protected] Subject: Re: [IPsec] query related to rekey
On Fri, Jan 20, 2012 at 2:18 PM, Prashant Batra (prbatra) <[email protected]> wrote: > After initiating a rekey or responding to a rekey, > > Is it correct to say, that any request should continue to be sent on old SA > until you receive a DELETE request or you send a DELETE request > to delete the rekeyed SA? Clearly some interlocking here would be nice, otherwise there will be a race and high likelihood of dropped packets, with ensuing pain at higher layers. IMO the CREATE_CHILD_SA reply indicates that the peer is ready to receive on that SA, but the local node may not be able to do so until the CREATE_CHILD_SA reply is processed, so the peer should NOT send on the new SA until it sees a DELETE of the old child SA. [Prashant] That's, from the responder side, but it may happen that the node initiating IKE_REKEY wants to initiate CHILD_SA_REKEY after sending IKE_REKEY_REQUEST as childsa is expired. So, it has to do it on old IKE_SA as he has not received the response. So is this case correct? In other words: - assume that the responder to a CREATE_CHILD_SA is ready to receive ESP/AH on the new SA SPI as soon as the responder's CREATE_CHILD_SA reply is received, and by corollary the initiator can start sending on the new SA immediately; - assume that the initiator of a CREATE_CHILD_SA exchange is NOT ready to receive ESP/AH on the new SA SPI until the initiator sends a DELETE payload deleting the old SA SPI, so the responder should NOT send on the new SA until it gets that DELETE. [Prashant] So, what is an ideal implementation that should be followed. I think, sticking to one standard, that's always send on the old SA until you send DELETE is a good option. Nico -- _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
