> (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. Steve -----Original Message----- From: Boris Pismenny <borispisme...@gmail.com> Sent: Wednesday, June 5, 2024 3:44 PM To: Steffen Klassert <steffen.klass...@secunet.com>; ipsec@ietf.org Cc: Antony Antony <antony.ant...@secunet.com> Subject: [IPsec] Re: Fwd: New Version Notification for draft-klassert-ipsecme-wespv2-00.txt 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? **Comments for hardware friendliness**: (1) Variable padding (especially per-packet) is bad for hardware. Is there any data on the benefit of aligning to 16B? >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. (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. (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. (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. --Boris On 28/05/2024 11:03, Steffen Klassert wrote: > Hi, > > we just published a new draft defining Wrapped Encapsulating Security > Payload v2 (WESPv2). It is designed to overcome limitations of the ESP > protocol to expose flow information to the network in a transparent > way. It introduces a flow identifier field that can be used to cary > flow information, such as 'anti replay subspaces', 'VPN IDs' etc. > > To preserve the usecase of the original WESP protocol (and to align > with Google PSP), it also defines a Crypt Offset to allow intermediate > devices to read some header bytes at the beginning of the inner packet. > > It also defines optional padding to align the cipertext to the need of > the peers. > > Steffen > > ----- Forwarded message from internet-dra...@ietf.org ----- > > Date: Tue, 28 May 2024 01:55:54 -0700 > From: internet-dra...@ietf.org > To: Antony Antony <antony.ant...@secunet.com>, Steffen Klassert > <steffen.klass...@secunet.com> > Subject: New Version Notification for > draft-klassert-ipsecme-wespv2-00.txt > > A new version of Internet-Draft draft-klassert-ipsecme-wespv2-00.txt > has been successfully submitted by Steffen Klassert and posted to the > IETF repository. > > Name: draft-klassert-ipsecme-wespv2 > Revision: 00 > Title: Wrapped ESP Version 2 > Date: 2024-05-28 > Group: Individual Submission > Pages: 12 > URL: https://www.ietf.org/archive/id/draft-klassert-ipsecme-wespv2-00.txt > Status: https://datatracker.ietf.org/doc/draft-klassert-ipsecme-wespv2/ > HTML: > https://www.ietf.org/archive/id/draft-klassert-ipsecme-wespv2-00.html > HTMLized: > https://datatracker.ietf.org/doc/html/draft-klassert-ipsecme-wespv2 > > > Abstract: > > This document describes the Wrapped Encapsulating Security Payload v2 > (WESPv2) protocol, which builds on the Encapsulating Security Payload > (ESP) [RFC4303]. It is designed to overcome limitations of the ESP > protocol to expose flow information to the network in a transparent > way and to align the cipher text to the needs of the sender and > receiver. To do so, it defines an optional Flow Identifier where > flow specific information can be stored. It also defines a Crypt > Offset to allow intermediate devices to read some header bytes at the > beginning of the inner packet. In particular, this preserves the > original use-case of WESP [RFC5840]. Optional padding can be added > for cipher text alignment. > > > > The IETF Secretariat > > > ----- End forwarded message ----- > _______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org -------------------------------------------------------------- Intel Research and Development Ireland Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. _______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
