On Thu, Jun 06, 2024 at 01:54:30PM +0000, Doyle, Stephen wrote: > > (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. > > +1 for this. > > With the current WESPv2 header format, an intermediate device that wishes to > perform ECMP using the FID will have difficulty finding the FID. For example, > in the presence of padding, what is the calculation that locates the start of > the FID field? The HdrLen gives the offset to the beginning of the "Rest of > Payload Data (i.e. past the IV, if present ...)" but the size of the IV is > algorithm dependant and won't be known to an intermediate device and so the > intermediate device can't use the HdrLen field to find the end of the header > and work backwards to the FID field. It would be much easier if either the > FID was after the initial 4 bytes of fields. Or if for some reason the > padding field needs to come before the FID field, have a field that specifies > the padding length to simplify the packet parsing. >
Intermediate devices should indeed be able to find the FID. I've just overlooked that this is not possible with the current format. The FID is at the end, because then it is directly followed by the ESP SPI which is also something that intermediate devices might be interested in. If the FID is in front, then there might be a gap between two interesting fields if padding is present. So yes, we need some padlen field. In particular because we also have problems to find the start of the ESP header without that. Would it be still beneficial for hardware to place the FID in front if we have a padlen field? Steffen _______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
