Christian Hopps writes:
> The replay window does not need to be the same size as the reorder
> window.
But effectively it is same as there is no use of having them
different.
If my reorder window is set to 2, and my replay window is set to 1000,
if there is any reorderining happening then even when replay window
allow packets 1, 5, 2 to be processed in that order, the reorder
window will drop packet 2 as it is outside the reorder window, thus
effectively replay window was also set to 2...
This is already explained in the draft:
When using the AGGFRAG_PAYLOAD in conjunction with replay detection,
the window size for both can be reduced to the smaller of the two
window sizes. This is because packets outside of the smaller window
but inside the larger would still be dropped by the mechanism with
the smaller window size.
So why does the section 2.5 require in-order processing of the
payloads stream to extract the inner-packets? This is not a
requirement for the regular IPsec, in regular IPsec it is valid to
process packets out-of-order provided they fit in the replay window,
but the last paragraph of the 2.5 do say that "the receiver processes
the now in-order AGGFRAG_PAYLOAD payload stream to extract the
inner-packets", which for me indicates that receiver cannot process
packets until it is sure they are in-order, thus it must wait until it
knows that missing packet is really lost, not just reordered.
This is even explictly said in case the congestion control is enabled
when the draft says that:
If congestion control is enabled, the receiver
considers a packet lost when it's sequence number is abandoned (e.g.,
pushed out of the re-ordering window, or timed-out) by the reordering
algorithm.
And I think we should explictly say that it is allowed to process
complete inner frames inside the one outer packet even when the outer
frame do have frames which are still missing data. I.e. in Appendix A,
if the ESP1 is lost, I would expect that recevier is allowed to
process ESP2 and forward those 60 and 240 octet packets out even when
ESP1 is missing and the first 100 octets in cannot be processed.
Also I would propose that receiver is allowed to process those two
full packets in ESP2 immediately when ESP2 is received, and not be
forced to wait until ESP1 drops out of reorder window before it deems
the ESP1 lost, and only after then start processing ESP2, 3, and so
on.
If you insist on requiring reordering packets always and in-order
processing and delivery, then extra text is needed to explain that
this is new service that is offered only by this, and not by normal
IPsec, and that this causes frames to be delayed by the reorder window
length every time there is any packet losses.
--
kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
