Introduced by Google in 2013, QUIC was finally standardized (RFC 9000) by the IETF as a ‘secure general-purpose transport protocol’, and published in May 2021.
As shown in Figure 1, QUIC combines functionality from multiple layers of the traditional ISO/OSI stack, including the transport layer functionality, security in the form of Transport Layer Security (TLS) and stream control to optimize higher layer applications.
In a paper we recently presented at the Internet Measurement Conference 2021, we at the Technical University of Munich deployed an Internet-wide measurement before the release of RFC 9000 to detect QUIC deployments, test whether successful handshakes could be done, and analyse TLS and QUIC specific configurations. During our study, we found more than 2.3 million IPv4 hosts and 300,000 IPv6 capable QUIC servers. Here’s how we found them and what we learned.
ZMap scans based on the QUIC Version Negotiation
We initially used a ZMap module that relies on the QUIC Version Negotiation mechanism to detect QUIC capable IPv4 and IPv6 hosts on the Internet. Sending an Initial packet with an invalid version 0x0a0a0a0a enforces a Version Negotiation packet from the server, including its set of supported versions. This revealed 2.1 million IPv4 and 220,000 IPv6 hosts.
Figure 2 shows the set of supported versions for IPv4 capable servers over time shortly before the release of RFC 9000. While many deployments still supported Google QUIC versions, most supported the latest draft that should have been deployed (Draft-29). Some operators announced QUICv1 shortly before the release.
Are IP addresses enough?
Due to the direct integration of TLS into QUIC, subsequent complete handshakes often fail without knowledge about hosted domains. Many operators rely on domain names to host multiple virtual hosts on the same IP address. Therefore, a valid Server Name Identifier (SNI) is required.
We tested this using QScanner, a highly parallelized stateful QUIC scanner. QScanner conducts complete QUIC handshakes and extracts information regarding general connectivity, QUIC specific parameters, TLS configurations and X.509 certificates.
Without an SNI, we only successfully finished handshakes with 7.25% of found IPv4 addresses and 27.66% of found IPv6 addresses.
QUIC detection based on alternative service discovery
To help measure missed domains, we analysed whether Alternative Service (Alt-Svc) discovery methods can be used and are widely deployed.
In HTTP, Alt-Svc headers can be used to redirect clients to different services, including HTTP/3 based on QUIC. We extracted headers from Internet-wide TLS scans, including HTTP requests, and found more than 36 million domains advertising QUIC support. Additionally, we found 146,000 new IPv4 and 208,000 new IPv6 hosts compared to ZMap scans.
Besides these headers, the IETF is working on new DNS Resource Records (RR), namely SVCB and HTTPS to allow a client to learn about endpoints or additional information for a specific endpoint before an initial transport layer handshake using the DNS. In theory, these records can help clients to discover deployed services with a simple DNS request but also allow researchers to deploy lightweight scans. However, we found these records are currently of little use, with a small adoption rate (see Figure 3) mainly dominated by Cloudflare.
Increased usage in the future has the potential to reduce overheads for clients and scanning efforts to detect QUIC, and other protocol deployments as well. These records allow clients to learn about offered services, ports and IP addresses (IPv4/6 hints) with a single DNS request.
Using QScanner to establish connections to IP address and domain results provided a considerably higher success rate of 76.06% for IPv4 and 90.70% for IPv6.
QUIC configuration diversity
QScanner allowed us to extract the transport parameters sent by the server during the TLS handshake. Transport parameters can be used to specify relevant connection properties such as the maximum number of streams or the allowed traffic volume.
In total, we saw 45 different configurations, combining all parameters. All configurations are published with our results.
Figure 4 depicts the usage of configurations based on targets.
The parameters active conn id limit, max ack delay and ack delay exponent default values were mostly used, while some parameters differed widely. For example, in the QUIC specification, max udp payload size is, by default, set to the maximum UDP payload size (65,527 Bytes). This value is used by 12 configurations, however, 12 further configurations use 1,500 bytes and overall, 10 different values can be seen.
Furthermore, data transmission related parameters vary within multiple orders of magnitudes. While some deployments only promote 8,192 bytes of initial max data, others support up to 16,777,216 bytes.
Read our paper for more results and details on our methodology. And check quicimc.github.io for updated QUIC deployment scan results.
Johannes Zirngibl is a Research Associate at TU Munich.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.