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
