[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipsec
Subject:    Re: [IPsec] Question about the draft-ietf-ipsecme-iptfs
From:       Christian Hopps <chopps () chopps ! org>
Date:       2021-05-04 12:37:08
Message-ID: m25yzysm6n.fsf () ja ! int ! chopps ! org
[Download RAW message or body]

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.

Tero Kivinen <kivinen@iki.fi> writes:

> 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.

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec


[prev in list] [next in list] [prev in thread] [next in thread]