Interesting thoughts from reddit here (user: VeryStrongBoi)

First, let me talk about QUIC adoption, so you understand the scale of the impact in 2025.

• Server-Side Support: According to W3Techs, HTTP3 (which runs on QUIC) is already 35% of all websites, which surpasses HTTP2 (which runs on TCP) at 33%:
• Client-Side Support: According to APNIC, QUIC is enabled on roughly 85-90% of clients, in almost every country in the world, except repressive regimes like China/Iran:
• Other apps: it's not just the Web that's using QUIC. SMB-over-QUIC is now supported in Windows 11 & Server 2025, as well as multiple Azure services. There's also DNS-over-QUIC, Media-over-QUIC, MASQUE, etc

Considering that the RFCs for QUIC are only 4 years since ratification in 2021, these adoption rates are extremely stunning for a L4 transport protocol, and it's because of the anti-ossification design choices that I'll discuss later (small wire image, stay out of the kernel). Adoption will only accelerate from here.

The performance impacts of blocking QUIC are actually massive. QUIC is the biggest upgrade to the infrastructure of the internet in over 50 years. It's not some niche thing that only Google uses, but is rapidly replacing TCP as the dominant L4 transport protocol of the internet, because QUIC is FAR superior to TCP in SOOO many ways. RFC 675 was the first standard version of TCP published in 1974, so TCP is over 50 years old, and has really been showing its age for some time now. God bless Vint Cerf and Bob Kahn for the revolutionary work they did at the time, but there were so many things they could not have anticipated back then. And because TCP had a fully naked wire image and all implementations were in the kernel, making any changes TCP over these past 50 years has proven incredibly difficult, because you have to get consensus from EVERYONE (Microsoft, Linux Foundation, Apple, the Middlebox vendors, etc.) which has meant that TCP is incredibly ossified.

That was a major insight that Jim Roskind (original creator of QUIC) understood: if you're going to make a transport L4 protocol, you want to reduce ossification as much as possible, so that means making the wire image as small as possible (viz using encryption for even the headers, or as much of the headers as possible) and putting as much of implementation into userland instead of the kernel. The way QUIC does that is that it only uses the kernel for port/socket control (via UDP) but does all connection-oriented functions (reliability, congestion control, encryption, multiplexing, etc) in userland. This makes it WAY easier for QUIC to evolve and improve over time. If you want to understand this aspect more deeply, please see RFC 8546 "The Wire Image of a Network Protocol"

One of the first limitations of TCP is that there was no inherent encryption built in, so SSL/TLS is a bolt-on that adds an extra round-trip. With TCP+TLS1.3, you've got 3-RTT latency, but QUIC gets this down to 2-RTT latency, because it does the session handshake and the TLS handshake in the same RTT. That's massive for making modern web experiences way more snappy. If you block QUIC with a middlebox, you're actually making the situation even much worse, because most browsers will burn a RTT trying QUIC, and then when that fails, revert back to TCP+TLS, so you now have 4-RTT or even 5-RTT in some situations. If you MUST block QUIC, at least try to also disable QUIC at the browser level using MDM/UEM, so that the clients know to not even try.

The second big limitation of TCP is that it didn't have any explicit and pro-active congestion control, just re-active congestion control where clients flood a link to death until ACK stop coming back, and only then does the client start backing off. This results in the infamous “sawtooth” pattern of TCP (Additive Increase Multiplicative Decrease (AIMD)). TCP ECN (RFC 3168, year 2001) was an attempt to ratify this, but adoptions has been extremely slow because of ossification. Mostly how network operators have tried to solve this problem is just buy bigger and bigger pipes, which works to a point, but also has unintended consequences of allowing for bigger and bigger DDOS attacks. QUIC has explicit, pro-active congestion control built-in from jump, as well as lot of anti-DDoS properties and mechanisms, which you can read about at length in RFC 9000.

A third big limitation of TCP that it has no native multiplexing capabilities, which results in head-of-line blocking problems for HTTP traffic (large elements impede delivery of small elements, causing pages to load slowly and erratically). Early attempts to solve this in HTTP1.1 were to just use a bunch of simultaneous TCP sessions for the same web page/app, but this produces a lot of unwanted overhead, and was crushing a lot of middleboxes & servers, so browsers had to limit this to max 6 TCP sessions per destination web page/app. HTTP/2 (SPDY) tried to improve on this with a multiplexed stream and compressed headers in a single TCP session, but because it was still riding on TCP, all the limitations of TCP (in-order packet delivery, sub-optimal congestion windows sizes and scaling rates, etc) made it so that the actual results with HTTP2 were often worse than multiplexing 6 HTTP1.1 streams, so adoption never really took off as much as people had hoped. QUIC/HTTP3 solves all of this by moving the multiplexing responsibility into userland, where we can make much more intelligent decisions about what to prioritize, retransmit, etc. If you want to understand this better, I highly recommend this talk from Jim Roskind at AWS 2022:

BUT the security impacts of letting QUIC through with no inspection are also massive, because URL Filtering and App-ID become impossible. So it's a real shame that PAN-OS still doesn't support inspecting/securing QUIC in 2025, over 4 years after the IETF RFCs for QUIC/HTTP3 were ratified in May of 2021. Especially considering that multiple other vendors have figured out how to inspect & secure QUIC to varying degrees, including:

• Fortinet, added 7.2.0, March 2022, supports both cert inspection and full decrypt (7.2.4 changed to QUIC inspection enabled by default)
• Forcepoint, 7.0.1, Feb 2023, supports only cert inspection
• Cisco, 7.6.0, June 2024, supports both cert inspection and full decrypt, but GUI/admin guide label it as “experimental” still
• Check Point, R82, October 2024, supports both cert and full decrypt, but only HTTP3 (doesn't yet support other L7 protocols over QUIC yet)

It seems like every other major firewall vendors is at least making progress towards QUIC inspection support, and some have very robust QUIC inspection support already. Again, I'm hopeful to see some news about 12.1 Orion adding support for this. Time will tell!