On Wed, Jul 29, 2020 at 03:57:01PM +0300, Tero Kivinen wrote: > Scott Fluhrer \(sfluhrer\) writes: > > As for the idea of moving the integrity check value before the > > encapsulated packet, well, that idea might help on your platform; > > however it strikes me that the advantage would likely be fairly > > platform dependent. > > Yes. In several kernel implementations the packets are formed as mbufs > which are linked list of pieces of packets, and in that kind of > environments there is easy ways to add/remove bytes to/from start or > to/from the end without needing to copy anything.
On Linux both can happen, packets can be constructed with a scatter-gather list or as a single linear buffer. In both cases we have headroom to add headers, but tailroom is not guaranteed. So in most cases we either need to allocate a new scatter-gather list entry for the trailer, or we have to allocate a bigger buffer and to copy the packet data. But yes, it depends on the platform. > In case you have single big buffer for the whole packet then removing > stuff from the end or adding stuff to the end is possible without any > copying provided you have enough space in your buffer. Adding stuff to > the beginning of the packet might require you to copy the whole > packet... We need space to add the headers at the beginning anyways. With the trailer, we need space on both ends. > > Also the need to read (while receiving packet) the ICV is only after > you have already decrypted the whole packet (if using AEAD), and want > to verify that the value matches. When the ICV is at the end of packet > that means it might already be in the cpu cache, as cpu read the last > bytes of the packet and the cache line might be big enough to include > ICV. If we need to go back to the beginning to read the ICV it might > not be in the cache anymore. Right, this is true indeed. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
