On Sun, Sep 5, 2010 at 11:56 AM, Yoav Nir <y...@checkpoint.com> wrote:
> > 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. > According to me, that's not very correct interpretation of windowing. My implementation goes ahead with the processing of message if the message is within window. Storing messages and not processing them is not very beneficial for the purpose of windowing concept. Related with your example, how an peer can delete an SA in message # 7, if message # 4 to create the SA was lost, the SA is not established yet. > > > > > 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 >
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
