From 8bfb1712d8b69c1faf2d9e23e741659c06f4a7df Mon Sep 17 00:00:00 2001 From: Nardi Ivan Date: Wed, 10 Aug 2022 18:25:44 +0200 Subject: QUIC: add support for 0-RTT packets received before the Initial RFC9001 4.6.1: "A client that wishes to send 0-RTT packets uses the early_data extension in the ClientHello message of a subsequent handshake; see Section 4.2.10 of [TLS13]. It then sends application data in 0-RTT packets." That means the client sends before the CH (in the Initial) and then the 0-RTT (in the same UDP datagram or not)". However, because of packet loss or out-of-order delivery, it might happens that a 0-RTT packet is received before the Initial (the original one or a retransmission). For example, Google and Facebook servers save 0-RTT packets for a small amount of time in hopes of receiving the corresponding Initial. Update the QUIC dissector to detect 0-RTT packets and keep looking for the Initial. Issue found by @utoni in #1706; the trace example has been taken from that PR. --- tests/pcap/quic_0RTT.pcap | Bin 2644 -> 8468 bytes 1 file changed, 0 insertions(+), 0 deletions(-) (limited to 'tests/pcap') diff --git a/tests/pcap/quic_0RTT.pcap b/tests/pcap/quic_0RTT.pcap index 7ade88654..95e7c2b6c 100644 Binary files a/tests/pcap/quic_0RTT.pcap and b/tests/pcap/quic_0RTT.pcap differ -- cgit v1.2.3