As a general principle, yes. But the HA extension already assumes that due to the failover, there is some discrepancy. The easy way out would be to write a protocol extension that just detects this discrepancy and kills the IKE SA. But that would mean a lot of IKE SA setups following a fail-over.
So in the context of the HA extension, we are willing to live with some unsynchronized state, and try to let it take care of itself. So the question is, if the peer already does not have the IPsec SA, does it add any information for us to send it a DELETE? Yoav -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Tero Kivinen Sent: 24 November 2010 13:18 To: Pekka Riikonen Cc: IPsecme WG Subject: Re: [IPsec] HA protocol replay protection Pekka Riikonen writes: > > On Tue, 23 Nov 2010, Tero Kivinen wrote: > : I think correct way to handle INVALID_SPI is that consider it as same > : as the other end would have sent delete for that his inbound SPI > : listed in the notification, and then send corresponding delete for > : your inbound SPI, which the other end will ignore as specified in the > : 2.25.1: > : > I'm not sure I agree. I think it's reasonable to assume that if you > receive INVALID_SPI notification instead of delete notification is that > the remote end has crashed or there is something else terribly wrong with > it and that it most likely doesn't have any state for the SA pair. General principle in the IKEv2 is that it is reliable protocol, and the state should not get out of sync. If you are getting INVALID_SPI for SA which you think is valid that means that other end is doing something wrong (for base IKEv2 case). _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
