Interop with PQUIC decryption issue

[The3ternum]

I seem to have stumbled on a small decryption issue that seems to exist on the regular implementations of aioquic and pquic, and therefore also exists on other implementations based on aioquic and pquic. I will explain my observations across multiple tests here.

I have also created an issue on the pquic page

I have the following cases:
Case 1: A local aioquic client that tries to download 999999 bytes from a local PQUIC server
(Default aioquic implementation, the PQUIC server has enabled the QLOG plugin)

Case 2: An online interop result from interop.seemann.io between an aioquic client and a PQUIC server
(Test: transfer, flag: DC)

Case 3: My modified local aioquic client that tries to download 999999 bytes from a local pquic server
(Modified aioquic implementation that enables multipath, the PQUIC server has enabled the QLOG plugin, as well as the multipath_rr_cond and multipath_qlog plugins)

In all three cases both endpoints seem to have some issues with decrypting certain packets that are being transmitted while the handshake is being performed.

In Case 1 I generated a QLOG-file on both endpoints (Ac_large.qlog and Ps_large.qlog), and I also stored the console output of the PQUIC server (Ps_large.txt) All files are stored in logs.zip. By loading both QLOG files in qvis.edm.uhasselt.be and selecting the actual traces for both the client and the server (not the GENERATED ones, see the first screenshot), we get a visualisation of the issue, as seen in the second screenshot.

After receiving an initial handshake packet from the PQUIC server, the aioquic client replies with an initial packet (pn: 1) and a handshake packet (pn: 2). The PQUIC server receives the first packet, fails to decrypt it, giving a "header or decryption error: 408." message and finally dropping the packet. The second handshake packet isn't mentioned in the console output. In response the PQUIC server replies with another handshake packet (pn: 1), and two 1RTT packets (pn: 0 and 1). The aioquic client receives these packets and can decrypt the handshake packet and the first 1RTT packet, but not the second 1RTT packet, logging a "packet_decrypt_error". The aioquic client thus acknowledges the handshake packet and the first 1RTT packet, but not the second 1RTT packet.
Later on, the PQUIC server identifies this second 1RTT packet as lost, as seen in the third screenshot. However, in this case the connection is able to continue, and the 999999 bytes are transferred, resulting in a clean connection termination.

By inspecting the client's QLOG and the server's LOG from Case 2 I assume that the same problem occurs, because the client QLOG contains a "packet_decrypt_error", and the server log contains a "header or decryption error: 408.". The connection is also able to continue and terminate as in Case 1.

Case 3 is more specific towards the multipath implementation in PQUIC and my implementation in aioquic. Nevertheless this decryption problem also occurs, leading to an additional ping-ack-loop issue that has been identified and is currently being patched.

My questions:
-What is causing the decryption problem?

(Small edit note: when generating your own traces, PQUIC saves its packets in the QLOG file with {"packet_type": "onertt"}, whereas aioquic saves the packets with {"packet_type": "1rtt"}, search and replace the PQUIC entries to "1rtt" so that both QLOG files have the same notation, otherwise the visualisation will show almost all packets as "lost".)

[The3ternum]

Additional observation: It seems that the undecryptable 1rtt packet that is being sent from the PQUIC server actually has a length that is greater than 1500 bytes (1523 bytes to be exact, excluding the header), thus the packet is rejected by the decryptor on the aioquic client.

[jlaine]

Are you able to transmit packets over 1500 bytes without encountering fragmentation?

Could you try raising the limit defined here:

aioquic/src/aioquic/_crypto.c

Line 13 in 04b28d8

#define PACKET_LENGTH_MAX 1500

What would be a better maximum length?

[jlaine]

Hello?

[The3ternum]

Sorry for the late response, I am no longer actively working on my own implementation that is based on aioquic.
As for the identified issue, I am not sure that you can transmit packets over 1500 bytes without potentially having fragmentation occur. I did, however, circumvent this issue by including a "max_udp_payload_size"-transport parameter whose value was lower than 1500 bytes. I did not perform any additional tests related to raising the limit defined in _crypto.c, so I am unsure about its effects on the data that is to be transported.