On Sep 8, 2010, at 1:50 PM, Tero Kivinen wrote: > Raj Singh writes: >>> 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. > > IKEv2bis says (in section 2.3. Window Size for Overlapping Requests): > > An IKE endpoint supporting a window size greater than one ought to be > capable of processing incoming requests out of order to maximize > performance in the event of network failures or packet reordering. > > so both processing the exchanges in order, or processing them out of > order is allowed, but the processing them out of order is the > preferred way.
I can't come up with any cases where doing the operations in different order results in a different state, but it seems to me that sequence numbers are there for a reason. Otherwise, why have sequence numbers at all? _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
