Terminating a Connection

Every connection that is established needs to be terminated at a later time. There are several ways of doing this. In the event of a violation of protocol specifications, an immediate close is used. If an endpoint sends an immediate close, the connection is terminated immediately, as the name implies. A stateless reset can be used in the case of connection problems. A specific example of a connection problem would be a recipient who receives packets from a former sender to a destination connection ID that no longer exists.

An IDLE timeout is an additional variant. If an endpoint inserts a max_idle_timeout in the transport parameters, a refresh must take place because a packet was successfully received and processed.

An IDLE timeout is another variant. If an endpoint adds a max_idle_timeout to the transport parameters, a refresh takes place because a packet has been successfully received and processed.

Security Measures in QUIC

One of the most important security aspects of QUIC is its mandatory TLS 1.3 encryption, which automatically includes forward secrecy, ruling out a subsequent decryption. The associated TLS handshake takes place directly in the QUIC handshake. Server authentication is mandatory, as in other TLS versions, whereas client authentication is an optional parameter. Unique keys are used in each connection, and the associated key material is used in both 0-RTT and 1-RTT packets.

Amplification attacks pose a challenge for UDP-based protocols because they cause a relatively small request to generate a huge response. Source address spoofing can be leveraged in this way to attack a third-party system. Therefore, the protocol developers placed great emphasis on address validation to mitigate the risk of spoofing attacks. This address validation comes into play both when the connection is established and when it is migrated. If the receiver has not yet completed address validation, the maximum size of the response packet is limited to three times the size of the previously received request. The payload must be at least 1,200 bytes in the initial packet; otherwise, padding is required.

A token exchange before compute-intensive operations helps to prevent server-side denial-of-service attacks. Handshake keys enable protection against handshake termination attacks following the initial packets, but measures have also been taken against optimistic ACK attacks (i.e., confirming the receipt of packages that have not yet been received). The developers also provide recommendations for preventing request forgery attacks.

Initial Implementations

This potential TCP successor is not just a protocol definition without any practical use, as is already underlined by numerous implementations. Other protocols in addition to the previously mentioned HTTP/3 are based on it. Among other things, they include a feature officially published in Windows Server 2022 Datacenter: Azure Edition: SMB over QUIC. This protocol encapsulates the Server Message Block (SMB) protocol for file transfer within QUIC to leverage its benefits.

Integrated TLS 1.3 encryption makes this particularly interesting if you need external access for mobile worker scenarios and internal access with strict security requirements at the same time. For the mobile scenario in particular, the ability to change the client's IP address or port is useful (e.g., when switching between hotspots and mobile data networks). This switch happens transparently for the end user in Microsoft's case. Microsoft is looking to enable public cloud-based filesystem access with a high level of security but with the same user experience as offered by local SMB file servers, without needing a dedicated virtual private network (VPN).

A QUIC approach resides in the controversial environment of DNS encryption: DNS-over-QUIC could be of interest as an alternative to DNS-over-TLS (DoT) and DNS-over-HTTPS (DoH) because it reduces handshake times, which in turn gives users a better experience thanks to faster performance. QUIC is already integrated and activated in current versions of Chrome and Mozilla Firefox.

Another interesting field of application for QUIC is the area of IP telephony. The first drafts of a RIPT protocol appeared in 2020. The protocol is being lauded as a potential successor to the SIP signaling protocol. SIP is still used without encryption in many cases. The problem here is that the TLS-encrypted variant is always based on TCP, which means greater latency in the initial connection setup (Figure 2); users notice this when establishing a call, for example.

Figure 2: Comparing the TCP connection setup for TLS 1.2 on the left side and for QUIC on the right. The latency advantage is clearly visible.

For an overview of the implementations, check out GitHub [6] for some implementations with the underlying programming languages and, for most part, the supported target platforms, QUIC versions, and roles (i.e., client, server, or both). Some solutions are already available there since the release of version 1 – more specifically, MsQuic, a library in C for Windows, Linux, and macOS; Neqo, a Mozilla/Firefox QUIC and HTTP3 implementation in Rust; Aioquic, a Python library; lsquic, a LiteSpeed QUIC and HTTP/3 library in C for Linux, FreeBSD, macOS, Android, and Windows; and quant, QUIC userspace accelerated network transfers in C.