On Sep 4, 2010, at 3:01 PM, Kalyani Garigipati (kagarigi) wrote: > > 1. If window size is say some five and range expected is 4-8, and if > peer has got all four requests with values 5,6,7,8 and 4 is lost, then > there would be no message id that can be used to send the notify > reset_window. > The initiator will not know which message Id should be used to send the > new notify.
It's actually worse than that. If message #4 was missed, and 5-8 were received, then messages 5-8 are stored, but not processed. This has to be so, because suppose message 7 deletes the SA that was created in message 4, you can't process it before message 4. In any case, message 4 has to be processed before 5,6,7, and 8. So it doesn't matter what kind of exchange or notifies you have in the new message, or whether it is within the message window or outside it. As long as message 4 was lost, the IKE SA is toast unless we have some special processing rules. > > And here the problem is not only to send the request, but also to > receive the request. The failover device should also know the > permissible range in which it can receive the requests from the peer. > > The idea to send a new informational exchange with message Id zero was > thought only because when the failover takes control it would not know > what message Id it can use to know the peer window values .This is the > basic problem of message Id synchronization, so having new notify itself > will not help. > > Regards, > Kalyani _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
