On Wed, Jun 19, 2024 at 12:01:32PM +0200, Boris Pismenny wrote: > On 07.06.2024 10:13, Steffen Klassert wrote: > > On Wed, Jun 05, 2024 at 04:44:25PM +0200, Boris Pismenny wrote: > > 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.
Agree with that. > > > >> >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! We did some more investigation on this. We think it might be better to do that more 'IPv6 like'. So instead of adding explicit padding and flow identifier fields, IPv6 extenstion header Options (RFC 8200 Section 4.2) could be adapted to WESPv2. Padding for ciphertext alignment would fall out of scope of this document then. If Padding for ciphertext alignment is needed, some other document can define the negotiation and use the Pad1 and PadN options to get proper ciphertext alignment. > >> (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. I think we can't completely avoid optional fields, but we plan to add an OptLen field in the next version of this draft, so it is easier to jump over all optional fields. When adapting IPv6 extenstion header Options to WESPv2, the parsing would be exactly the same as for IPv6 extenstion header Options. We plan to publish a new version that describe the 'Options idea' soon. _______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
