On 2/13/2023 7:25 AM, Boris Pismenny wrote:
On Mon, Feb 13, 2023 at 7:20 AM Christian Huitema <huit...@huitema.net
<mailto:huit...@huitema.net>> wrote:
This issue, packet number encryption versus hardware acceleration, was
discussed in quite some depth during the standardization process. The
current design was adopted with full knowledge that hardware
acceleration will require some harder work than if numbers were in
clear
text.
I did look through the mailing list archives, and I understand that
adding it
now is non-trivial. I didn't see a previous discussion on the mailing
lists of
negotiating plaintext packet numbers as part of the handshake, and since
it will benefit high-performance users I would like to draft such a
proposal.
Boris, you may try to propose an extension or a new version that
changes
this specification, but such changes will have to be negotiated and
agreed by the client and server for each connection. Very likely, a
significant number of these clients and servers are going to reject the
extension. So, even if you do define this extension, your hardware will
still have to support the existing specification to talk to this
unmodified clients or servers.
Thanks Christian, a negotiated extension is exactly what I would like to
propose. Indeed, both client and server must support this for it to work,
and that's perfectly fine for many use-cases, such as high performance
computing and data centers. Do note that hardware support for clients
and servers that reject this feature is an orthogonal question---NIC
based encryption acceleration is usually combined with fully compliant
software stacks that handle packets which hardware cannot process.
For a discussion of software stacks for NIC hardware encryption
acceleration for QUIC, see:
Linux:
https://lwn.net/ml/linux-doc/20220817200940.1656747-1-adel.abush...@gmail.com/
<https://lwn.net/ml/linux-doc/20220817200940.1656747-1-adel.abush...@gmail.com/>
Windows:
https://github.com/microsoft/quic-offloads
<https://github.com/microsoft/quic-offloads>
What would be the next step for such a proposal? an RFC draft?
a discussion at IETF116? I think that it makes more sense to start
with DTLS1.3 as it seems to require only an extension, compared
to a new QUIC version that changes an invariant.
The process for any proposal is to submit a draft to the relevant
working group. I have no idea whether you will find a better reception
in QUIC or in TLS. Your proposal amounts to lowering security in order
to improve performance. The working groups may very well find that this
is not a good idea.
-- Christian Huitema
