**
*Dear QUIC WG,*
*
I’m Kashyap Thimmaraju, a postdoctoral researcher at Humboldt University
Berlin. Recently I discovered a couple of attacks with the QUIC
protocol. Lars Eggert recommended that I share my findings with the WG
to discuss the impact and relevance of these findings.
In this email I’ve described my work on the new connection ID (NCID) for
server implementations.
ANALYSIS
The draft does not specify how servers should handle new CIDs (NCID) where:
1.
All the NCIDs are the same as the client generated SCID
2.
All the NCIDs are the same as the client generated DCID
3.
All the NCIDs are the same but different from the client generated
SCID and DCID
EVALUATION
The primary goal of my evaluation is to observe how implementations
behave to the 3 test cases outlined in the analysis. To conduct this
experiment I adopted the following methodology. First, I created a
client that uses deterministic CIDs for the source and destination CIDs
and the NCIDs (I modified LiteSpeed Technologies open-source QUIC
client). Second, I used 15 implementations from those listed on the QUIC
Working Group’s GitHub page1: either manually built Docker containers or
the public test server. The list of servers tested are shown across the
rows in the table below. To conduct the experiment, I always had the
client open a QUIC connection with source CID 1 and destination CID 2.
The NCID that was then used was either all 1, or all 2, or all 3. The
connection was kept open (if possible) for a maximum of 10s with the
server, and then closed. I saved the debug logs of the client, packet
traces and session keys. I then repeated the process for each of the 15
implementations. Finally, to obtain the results of the test, I searched
the debug log of the client or the packet trace to confirm whether the
QUIC connection obtained a successful handshake or not. If not, I
collected any error messages.
RESULTS
The results from my evaluation are shown in the table below. In
particular, I found that either the handshake succeeded or the handshake
failed due to a PROTOCOL_VIOLATION, Error Code: 10 message from the
server. When I had tested this on quant early on, çase aresulted in
crashing the server (see https://github.com/NTAP/quant/issues/68
<https://github.com/NTAP/quant/issues/68>). The difference in behaviours
raises the question on how servers should respond to such messages and
what amount of detail should be provided in the reason of the error message.
TEST CASE : HANDSHAKE COMPLETED : PROTCOL VIOLATION
A : Aioquic, Cloudflare, Neqo, Nginx, Pquic, Akamai, Ats, Chromium, F5,
Quinn, Mvfst : Lsquic, mvfst, ngtcp2, picoquic, quant, quicly
B : Aioquic, Cloudflare, Neqo, Nginx, Pquic, Mvfst : Ngtcp2, picoquic,
quant, quicly
C : Aioquic, Cloudflare, Neqo, Nginx, Pquic, Akamai, Ats, Chromium, F5,
Quinn, Mvfst : Lsquic, ngtcp2, picoquic, quant, quicly
*
Sincerely,
--
Dr.-Ing Kashyap Thimmaraju
Lehrstuhl für Technische Informatik
Institut für Informatik
Humboldt-Universität zu Berlin
Besucheranschrift:
Rudower Chaussee 25, 12489 Berlin
Haus 4, 3. OG
[email protected]
http://www.ti.informatik.hu-berlin.de
