On 07.06.2024 10:13, Steffen Klassert wrote: > 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.
This doesn't actually address my original request because using the "SHOULD NOT" term means that implementation MAY still change it. I suggest using the more restrictive "MUST NOT" to prevent this and to add checks in the datapath to ensure this isn't violated and to drop packets that do violate this. I think that negotiation is very desirable given that it is constant because it will allow peers to optimize based on an expected packet format. >> 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. Interesting, but what about the cost of increasing packet headers on both: (1) protocol efficiency (percentage of user-data to headers); and (2) cache efficiency. These traded-off aspects are sometimes more important. > >> >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. Cool, thanks! > >> (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? Hardware parsing, unlike software parsing, attempts to get all packet fields in one go and having parsing depend on some other fields makes it more difficult. If these fields are optional, they appear at the end, and they do not need to be match-able by hardware, then hardware might just skip them. The current format has optional fields in WESP before the ESP header, so we need dependent reads to find the ESP SPI, which is undesirable. > > 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
