Recommended method to block QUIC and HTTP/3

Reason to block QUIC

QUIC is an alternative method to transmit web content that doesn't use TCP and forms the transport basis of the nascent HTTP/3 protocol. While QUIC/HTTP/3 does include some performance enhancements versus HTTP/2 and HTTP/S, the protocol is not yet managed to the same extent by the Zscaler Secure Web Gateway (SWG). It is therefore recommended to block QUIC and force communications into HTTP/2 or HTTPS which are fully managed by the SWG.

QUIC is a UDP-based protocol so the Cloud Firewall is required to block and force the client to use a different protocol like HTTP/2 for web traffic.

Blocking QUIC

Most QUIC is UDP over dest:443.

If the default Cloud Firewall rule is enabled to block all that is not allowed and no rule explicitly allows traffic associated to QUIC then QUIC will be blocked and no further action is required.

If the Cloud Firewall is configured to default allow then the core best practice policy to block QUIC is a rule that has the network service “QUIC” selected with the action to “Block/ICMP”.

The selection of the ICMP block not only drops the UDP packet but also sends the client an error message of Type 3 (Destination Unreachable) and Code 13 (Communication Administratively Prohibited) via ICMP which allows the client a potentially faster switchover to another web transport method. This in turn results in a better user experience with little lag as the client learns quickly that QUIC is not working.

Since QUIC is not bound to only use to the default destination port for HTTPS (dest:443), it is further recommended to block UDP over HTTP:80. This is easily done by modifying the existing network service definition for QUIC to include UDP over destination port 80. Alternatively, a new network service can be defined for just QUIC using UDP:80 but then this network service needs to be added to the above described Cloud Firewall rule.

Using Network Application (DPI) identification of QUIC

The deep packet inspection identification of traffic is a good way to have a very high and independent certainty of any given application – including QUIC. Using the network application “QUIC” in a subsequent rule (so in a new, lower ranked rule addition to the network service-based rule recommended above), is a good way to identify QUIC regardless of port used.

The tradeoff in any DPI-based identification is the number of packets that are allowed before the certainty of identification occurs. This can mean packets are allowed before the network application is identified as QUIC.

So it is recommended to use the network service-based identification of QUIC first and with the highest possible rule rank according to desired policy. Then have the network application identification of QUIC at a lower rule ranking and thereby applying to fewer possible flows. This type of recommendation for the use of a network application-based rules and applying these rules at a lower rank order and after rules with first-packet identifiable flows (like those with network services or application services) is a standard recommendation in Cloud Firewall.

Related topic: When "allow due to insufficient app data" log entry value appears and when it does not