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. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
