Subject: Re: [IPsec] Question about the draft-ietf-ipsecme-iptfs

From: Tero Kivinen <[email-masked]>
Date: Tue, 4 May 2021 12:13:25 +0300

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. 
-- 
[email-masked]

---

From: Christian Hopps <[email-masked]>
Date: Tue, 04 May 2021 08:37:08 -0400

I feel like this is going in circles.

If you have a slow link, which is what you were highlighting, you set your re-order window to 0 -- you don't need to guard against reordering.

If you still want to detect replay attacks though, you leave your replay window at some large number. The replay window is trying to detect replay attacks, not handle re-order packets. This has nothing to do with packet acceptance at this point, as that job was taken over by the reorder window.

They will both do their jobs correctly.

I initial objected to the request for adding that text you quote b/c these things are different and I didn't see the value in conflating them just to provide for "advice" for some scenarios. If anything we should remove that section if it's causing you concerns now.

Thanks,
Chris.