On Wed, Jun 05, 2024 at 04:44:25PM +0200, Boris Pismenny wrote: > Hi, > > I have a few questions and a few comments on how > to make this more hardware friendly, like PSP. > Note that making it hardware friendly will likely > improve highly tuned software performance too. > > **Questions**: > (1) What is the purpose of matching the WESP2 next > header and the ESP next header? won't it be better > to remove/replace the ESP trailer's next header > and padding?
WESPv2 acts a a wrapper around ESP, we can't change anything on the ESP protocol itself. Also, this matching is just done if the peers agree to show parts of the inner headers by using a nonzero cryptoffset. We don't want to leak the next header if cryptoffset is zero. > > **Comments for hardware friendliness**: > (1) Variable padding (especially per-packet) is bad for > hardware. It should not change on per packet basis. We placed this in the draft: The chosen padding size SHOULD NOT change for a given Child SA. (Authors note: Should the padding size be negotiated?) So maybe it can be even negotiated to meet the requirements of both perrs. > Is there any data on the benefit of aligning to 16B? On some archtitectures SIMD and AVX instructions perform better with proper alignment. The 16 byte are mentioned because the ciphertext is already aligned on a 8 byte boundary, so you should reach at least 16 bytes if padding is used. > >From a hardware perspective the preferences regarding > padding are: (a) remove it entirely; (b) use a constant > amount of padding that is negotiated per-flow; or > (c) add a field that explicitly indicates the length of > padding in the packet. We should have (b), we need (c) and we can discuss about (a). Let's wait on other opinions. > > (2) Parsing is easier when optional/variable length > fields appear at the end rather than the beginning. > For example, if you could move ESP closer to the > start of the header that would be good. What do you mean by that? We could make the FID always present if that would help. > > (3) Fields that should be match-able by hardware > should appear at the beginning. The FID, for example, > seems like a field that should go to the beginning. I've commentd on this in the other mail. > > (4) All fields that can be constant per-flow should > be pre-negotiated, such that it is possible to assume > that all packets of a flow have the same flags. For > example, the FID and padding length should be decided > at negotiation and if they're unused then they should > be prohibited for all packets of this flow. Agree with that. Steffen _______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
