On Fri, Aug 16, 2024 at 07:32:06PM +0300, Tero Kivinen wrote: > Paul Wouters writes: > > On Fri, Aug 16, 2024 at 10:09 AM Tero Kivinen <kivi...@iki.fi> wrote: > > > > The difference in implementations is minimal, but sending lower > > 32-bits first keeps the ESP backward compatible with different > > firewall, deep packet inspection etc middleboxes, which might check > > sequence number and filter stuff if it sees duplicate sequence > > numbers. > > > > Supporting this would be pretty much at the bottom of my priorties. > > > > I am far more interested in what is best for hardware optimalization. > > Having lower 32-bits first will allow checking those bits even before > the upper bits are even received.. On the other hand I do not think > there is any difference in hardware as you most likely want to check > ICV first anyways before checking replay window, and that requires > receiving full packet anyways. > > For hardware I do not think order of 32-bit words makes any > difference. I do not think there is any difference in software either, > so this is should not affect performance, except you can perhaps use > the old hardware to check lower 32-bits of the sequence number if it > is in same location than before.
If the hardware can read the full 64 bits with one clock tick, it is just an additional swap which should be cheap. In software you also need to swap to align with the memory layout of the number to compare with. But this burns some cpu cycles, so it is not that cheap as in hardware. I understand the reason why to not change the existing ESP header layout. But maybe it is really better to focus on something new and do it right from the beginning, instead of negotiating these things for existing ESP. _______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
