QUIC is a Layer 4 (Transport Layer) protocol created by Google to speed up data transmission rates between devices across IP networks. QUIC was first implemented in 2012, connecting Chrome to Google servers. QUIC is adopted by 7.5% of all websites today.1 By June 2023, around 40% of Chrome’s traffic was reported to be using QUIC2, and according to CloudFlare, 28% of all of its HTTP requests were HTTP3 (using QUIC-UDP).3 QUIC is also a major protocol for content requests made via Firefox (35%), Safari (18%) and Chromium-based browsers such as Microsoft Edge (40%).4
The number of applications using QUIC has grown rapidly in recent years. According to Engineering at Meta, 75% of Meta’s Internet traffic uses QUIC and HTTP/35, primarily driven by Facebook and Instagram. Other applications that use QUIC are Snapchat, Uber, ChatGPT and Google apps such as Gmail and YouTube.
QUIC – behind the scenes
Advancements in data transmission gave rise to multiple protocol stacks curated to meet the communication requirements of different types of applications. The Layer 3 IP protocol forms the base of all IP application stacks. The transport layer (Layer 4) builds on this, and features two parallel stacks: the connection-oriented stack and the connection-less stack.
TCP vs. UDP vs. QUIC
The traditionally used connection-oriented stack uses the transport control protocol (TCP). It runs an extensive handshake process which involves the exchange of SYN and SYN-ACK packets between the sending and receiving devices. Where encryption such as TLS 1.3 is used, this is then followed by ClientHello, which contains Server Name Indication (SNI), Application Layer Protocol Negotiation (ALPN) and key share information. This information is reciprocated with the ServerHello. Data transmission begins only when the entire handshake process has been completed. Given the reliability of the transmission and low error rates, TCP makes a perfect protocol for applications such as web browsing, email and file transfer, supporting corresponding Layer 7 protocols such as HTTP, SMTP and FTP.
The user datagram protocol (UDP) is another transport layer protocol. It forms the connectionless stack. In UDP, datagrams (instead of packets) are transmitted in a ‘rapid-fire’ manner without any acknowledgement from the receiving device. UDP uses port numbers to identify different user requests and uses the checksum feature to validate if all the packets have been received. UDP is very useful for applications that prioritize high speeds and low latency as data is transmitted from the first instance. Applications using UDP, however, must have a tolerance for loss. A video streaming application, for example, can stream a movie even with a few missing video frames. Other applications that work well with UDP are VoIP and gaming applications. UDP supports various application and upper layer protocols including DNS, SNMP, network time protocol (NTP), RTSP and TFTP. Encryption over UDP can be executed via application-level protocols such as SRTP and ZRTP.
QUIC is also a network layer protocol. However, given that most devices are configured to support either TCP or UDP, QUIC uses UDP as its base protocol. QUIC combines the advantages of connection-oriented transmission of TCP (guaranteed delivery) and connection-less transmission of UDP (low latencies).6 QUIC uses multiplexing, which eliminates head-of-line blocking, and features zero round-trip time (0-rtt) resumption. It also supports seamless migration across different networks. These features are topped with a built-in cryptographic handshake and encryption based on TLS 1.3. There, the entire communication, including ClientHello information, is concealed to anyone outside of the established connection between the end points.
Applications can be programmed to run on one or more stacks. For example, the initial versions of HTTP (i.e. HTTP1 and HTTP2) use a connection-oriented stack that combines TCP and TLS. HTTP3, however, uses the connection-less stack which combines UDP with QUIC. In this case, QUIC forms the security protocol as well as part of the application and transport protocol.
Visibility challenges with QUIC
While QUIC is perfect for securing applications such as gaming, video conferencing and IPTV, it poses serious visibility issues for networks. Traditionally, networks can inspect ClientHello information to ascertain the identity of an encrypted application. For example, TLS 1.3-over-TCP exposes SNI, ALPN and key share information, while ESNI-over-TCP exposes ALPN and key share. QUIC, however, hides the entire ClientHello. As a result, networks are no longer able to read the host name or the domain name of the website. They cannot establish the protocols supported by the client (e.g. a VoIP app) as well as the key exchange method used and the length of the key share for encryption.
Consequently, existing traffic monitoring tools that rely on ClientHello information and handshake patterns to analyze encrypted traffic lose vital traffic insights when it comes to QUIC. This makes intelligent traffic management impossible as application-based policies can no longer be executed. Traffic routing, security filtering and content caching become complicated as these policies are mostly application-specific. QUIC also introduces new gaps in network security, as cybersecurity solutions cannot profile and filter traffic flows by application risks, or identify threats hidden in encrypted flows. With the steady rise in QUIC traffic, networks are expected to grapple with the progressive loss of visibility across their networks.
Mitigating QUIC-based loss of traffic visibility with DPI
To address the traffic visibility challenges introduced by QUIC, ipoque has introduced encrypted traffic intelligence (ETI). ETI is embedded in the cutting-edge deep packet inspection (DPI) software by ipoque, R&S®PACE 2 and R&S®vPACE. Encrypted traffic intelligence combines machine learning, deep learning and high dimensional data analysis with advanced caching methods to identify and classify underlying traffic flows. By combining ETI with behavioural, statistical and heuristic analyses, the DPI software by ipoque is able to identify protocols, applications and services across encrypted traffic, in real time.
Leveraging ETI, R&S®PACE 2 and R&S®vPACE can accurately determine the application layer protocols that use QUIC. Examples of these protocols are HTTP (1.1,2,3), STUN, FTP, IMAP, POP3, XMPP and SMB. Our next-gen DPI software R&S®PACE 2 and R&S®vPACE can identify the HTTP3 protocol and classify the underlying packets into applications, such as Facebook or YouTube, and break down the traffic further into chat or video traffic. This information is important for content filtering and content caching tools. Similarly, R&S®PACE2, deployed within a network packet broker or a next-gen firewall, can identify applications such as WhatsApp, Cisco WebEx or Microsoft Teams. Combined with traffic metadata information such as speed, jitter, latency and round-trip time, ipoque enables networks to analyze each application in depth while feeding real-time data into networking tools such as routers, CDNs, tethering or IP probes.
Our DPI software is especially useful in identifying anomalies and potentially malicious flows originating from QUIC traffic. An example for that is QUIC flood DDoS attacks using reflection and amplification methods. IPS/IDS systems can leverage traffic intelligence from ipoque to block illegitimate QUIC-based requests that attempt to cripple the victim servers. Malicious C2 QUIC traffic is another vulnerability that can be detected using ipoque’s analyses of traffic irregularities.
Being QUIC(K) and secure
There are ongoing efforts in every part of the world to further enhance QUIC in terms of security and data privacy. This, however, does not have to become a hurdle for networks in monitoring and managing traffic flows. With ETI by ipoque, networking and cybersecurity vendors can easily arm their tools with real-time intelligence into not just encrypted traffic, but also anonymized and obfuscated applications. What is more, ETI comes in the form of highly scalable and light-weight DPI engines that can be implemented in any networking environment. With ETI and DPI, QUIC can continue securing and strengthening data communications, without any toll on traffic visibility and transparency.
Sources
[1] https://w3techs.com/technologies/details/ce-quic
[2,3,4] https://blog.cloudflare.com/http3-usage-one-year-on/
[5] https://engineering.fb.com/2020/10/21/networking-traffic/how-facebook-is-bringing-quic-to-billions/
[6] https://www.debugbear.com/blog/http3-quic-protocol-guide
