A network team turns on a new inspection appliance and finds that a large share of traffic to major services, including some AI front ends, is not being inspected. The appliance understands connections built on TCP. Much of the traffic is using QUIC, carried over UDP, which the appliance does not parse. The team has a choice: block QUIC and force the traffic back onto TCP where the appliance works, or let it pass uninspected. This chapter explains why that choice exists.
The transport layer is where a stream of data is directed to the right program on a machine, and where the idea of a connection lives. What a firewall or proxy can track about traffic, before any decryption, is largely decided here.
Ports and the transport layer
The network layer gets a packet to a machine; the transport layer gets it to the right program, identified by a port number. A web server listens on a known port, 443 for encrypted web traffic, and the client uses a temporary port of its own. Any observer, and any firewall, can identify a flow by five values together: the source address and port, the destination address and port, and the protocol. This set of five is the basic unit a firewall uses to permit, deny and track traffic, and it is visible without reading any content.
TCP: connections with state
TCP provides a reliable, ordered stream between two programs. It begins with a defined setup, the three-step handshake, in which the client and server exchange opening packets to agree they are both present and ready. From then on, each side numbers the data it sends so that loss can be detected and retransmitted, and order restored. The connection is explicit: it is opened, used, and closed.
That explicit state is useful to a defender. A firewall can hold a table of active connections and allow return traffic only for connections that were properly opened from inside. It can see a connection start, to a given address and port, and end. Traditional network inspection assumes this TCP structure: a connection it can see beginning, follow, and hand to a proxy.
UDP: no connection, by design
UDP sends individual packets with no setup, no ordering and no delivery guarantee. It is used where speed matters more than reliability, and where the application handles any recovery itself. For a firewall, UDP has no connection to track in the TCP sense; it sees packets to and from a port, and applies rules to those. UDP has always carried real-time media and DNS. It now also carries QUIC, which changes the picture.
QUIC: a connection built inside UDP
QUIC is a modern transport that runs over UDP and rebuilds the reliability and ordering of TCP inside itself, while integrating encryption from the start. It underlies HTTP/3, the current version of the web's application protocol, and now carries a large share of traffic to major services. Two of its design choices matter for inspection.
First, QUIC encrypts almost everything, including most of its own transport information, from the first packet. Where a TCP connection exposes its setup and much of its control data in clear text, a QUIC connection exposes very little beyond the addresses and ports. A device that only knew how to read TCP control data sees almost nothing useful in QUIC.
Second, a QUIC connection is identified by a connection identifier carried inside it, not by the address and port pair. This lets a connection survive a change of network, for example a laptop moving from Wi-Fi to a mobile hotspot, without breaking. The connection continues under the same identifier from a new address. Any tool that tracked the session by its address and port loses it at that point.
What this means for controlling AI traffic
Before any decryption, a control at the transport layer can see the same small facts for AI traffic as for anything else: which internal device connected to which external address and port, and when. That is enough to enforce address and port rules, and enough to record that a connection happened, subject to the attribution limits of the previous chapters. It is not enough to see a prompt.
QUIC narrows even this. An inspection point that terminates TCP connections, the standard design for a proxy, does not receive QUIC connections at all, because they are not TCP. If the organisation does nothing, browsers that prefer QUIC can reach services over UDP and bypass a TCP-based proxy entirely. The common response is to block UDP on port 443 at the firewall. Browsers treat QUIC as optional and fall back to TCP with TLS when UDP is blocked, which returns the traffic to the path where the existing proxy and its inspection work. Blocking QUIC is therefore not about stopping access; it is about forcing traffic onto the path the organisation can inspect. (high)
If QUIC is not blocked and the inspection point only handles TCP, AI traffic over HTTP/3 passes without inspection while appearing, in summary, as ordinary encrypted traffic to a known address. Connection migration means a session cannot be reliably followed by address and port, so tools built on that assumption undercount or lose sessions. QUIC's early-data feature lets a client send application data in its first packet to a server it has spoken to before, which reduces the setup an observer can see.
Blocking UDP 443 to force fallback is effective only where the organisation controls the egress, so it does nothing for a device off the corporate network. And forcing fallback to TCP still only yields inspectable content if the organisation also decrypts TLS, which is the subject of the next two chapters. Transport choices decide what can be tracked; they do not, by themselves, reveal content.
- List the values that identify a single flow to a firewall, and state which of them, if any, reveal the content of a prompt.
- Explain why blocking UDP on port 443 can improve an organisation's visibility of AI usage rather than reduce it.
- A monitoring tool reports fewer sessions to an AI service than help-desk reports suggest are happening. Give two properties of QUIC that could explain the undercount.
- Your proxy inspects TCP but not QUIC, and QUIC is not blocked. Describe the path a browser can take to reach an AI service without passing through the proxy.
Sources
- RFC 9293, Transmission Control Protocol (TCP). IETF, August 2022. rfc-editor.org/rfc/rfc9293. Checked 9 August 2026. (high)
- RFC 768, User Datagram Protocol. IETF, August 1980. rfc-editor.org/rfc/rfc768. Checked 9 August 2026. (high)
- RFC 9000, QUIC: A UDP-Based Multiplexed and Secure Transport. IETF, May 2021. rfc-editor.org/rfc/rfc9000. Checked 9 August 2026. (high)
- RFC 9001, Using TLS to Secure QUIC. IETF, May 2021. rfc-editor.org/rfc/rfc9001. Checked 9 August 2026. (high)
- RFC 9114, HTTP/3. IETF, June 2022. rfc-editor.org/rfc/rfc9114. Checked 9 August 2026. (high)
- RFC 9312, Manageability of the QUIC Transport Protocol. IETF, September 2022. rfc-editor.org/rfc/rfc9312. Discusses what QUIC exposes to on-path devices. Checked 9 August 2026. (high)
Last updated 9 August 2026