The *spec says "**If an endpoint receives a NEW_CONNECTION_ID frame that repeats a previously issued connection ID with a different Stateless Reset Token or a different sequence number, or if a sequence number is used for different connection IDs, the endpoint MAY treat that receipt as a connection error of type PROTOCOL_VIOLATION." This is a "MAY", and it is not surprising that some implementations have stricter checks than other.*
*Note that clients may well send a single ***NCID with the same value as the client generated SCID. That's not a protocol violation.** **-- Christian Huitema ** ** *It does not test against the * On 11/12/2020 8:36 AM, Kashyap Thimmaraju wrote: > > ** > > *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). 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
