You deny udp/443 at a branch to keep sessions on TCP — what do you gain, and what breaks?
answer
- a second carrier for the same session
- protocol plus port, not port alone
- well-behaved clients fall back; some do not
- pinning removes inspection at any price
- the exception list is the lasting cost
basics
~20 sYou gain one carrier fewer to reason about: most clients that prefer QUIC fall back to TCP with TLS. You pay setup delay for everyone, and a QUIC-only client that pins its certificate breaks outright.
solid answer
~50 sThe gain is that a session cannot silently leave over a carrier you never wrote a rule for. QUIC rides UDP/443, so an ACL that only ever considered TCP had a hole; denying UDP/443 pushes well-behaved clients back onto TCP with TLS, which your existing rules, destination lists and flow records already cover. The costs land on different people. Every client that would have used QUIC pays an extra round of connection setup, which users notice on a high-latency link, and interactive media degrades. The case that decides the design is the client with no fallback: a vendor agent speaking only QUIC and pinning its own certificate cannot be pushed onto TCP and cannot be inspected at any price, so it gets a destination-scoped exception or the function stops. That exception list, and its review, is what the block really costs.
go deeper
Know that QUIC is carried over UDP on port 443, so a rule written only for TCP does not cover it, and that blocking it is a decision with user-visible effects.
Explain the fallback behaviour and why it is not free: extra connection setup for every affected client, and degraded interactive media on a poor link.
Demonstrate the rollout: measure what uses it first, sequence the change with a rollback owner, scope exceptions by destination, and state the residual opacity that remains afterwards.
Own the trade between one describable carrier and an exception list somebody must maintain forever at a site with no dedicated operator, and say who signs for the function you may have to stop.
## Why the rule exists at all A branch ACL written years ago in terms of TCP destination ports quietly stopped describing reality when applications began carrying the same sessions over QUIC, which is a UDP transport using destination port 443. If the ACL permits UDP broadly, or was never revisited, a session can leave over a carrier that none of the TCP-shaped policy, destination restrictions or expectations applied to. Denying UDP/443 is the cheap way to force everything back onto the carrier your policy actually describes. This is the leaf's whole point in a second form: the *protocol and port pair* is a claim the sender makes. If you only wrote rules about one pair, the sender simply makes the other claim. ## What you actually gain - **One carrier, one set of rules.** Destination allow-lists, deny logging and flow records all apply to the traffic, instead of applying to the half of it that stayed on TCP. - **Connection setup and teardown you can count.** TCP sessions produce start and end you can see in flow data; you lose that distinctness when the same session becomes a UDP flow that a collector times out. - **No silent path around an existing decision.** If somebody scoped 443 to a destination list, that scoping now covers the whole session rather than being sidestepped by a different transport. ## What it costs, and who pays - **Latency for everyone.** A client that prefers QUIC has to discover the block and fall back to TCP with TLS. Modern clients do this reasonably quickly, but it is extra setup on every affected connection, and on a consumer broadband link with real round-trip time this is what users describe as "the site is slow at the branch". - **Interactive media quality.** Conferencing and streaming clients chose the newer transport for its per-stream loss recovery; forcing them back onto a single TCP connection can visibly degrade calls at exactly the small site with the worst link. - **Clients that do not fall back.** This is the decisive case. A vendor agent, an appliance, or an embedded client may speak only QUIC. There is no fallback to force, so the block does not degrade it — it stops it. And if that same client pins the certificate it expects, there is no version of "inspect it instead" available either, at any price and regardless of budget. Your options collapse to: permit it, scoped as tightly as you can to its destinations, or lose the function. - **The exception list itself.** Every permitted exception is a line somebody must justify, review and eventually be unable to explain. At a twenty-person branch with no dedicated operator, an exception list of even ten entries is a real burden, and it is the cost that outlives whoever made the decision. ## How to make the decision defensibly 1. **Find out what actually uses it before you deny it.** Deny with logging first, or count what a deny would have hit, so the breakage list is discovered by you rather than by the branch on a Monday morning. 2. **Sequence the change.** Apply it outside business hours at one site, keep the previous rule ready to restore, and agree in advance who decides to roll back. 3. **Scope the exceptions by destination, not by port.** "udp/443 to this named set of destinations" is a far narrower statement than "udp/443 any", and it is the only narrowing available when you cannot look inside. 4. **Write down the residual.** After the block and the exceptions, you still cannot say which application crossed on tcp/443. The block removed a carrier; it did not add identification. ## The wrong answers this question is aimed at The first is "QUIC will just fall back, so the block is free" — free is exactly what it is not, and the client that cannot fall back is the one that will define your week. The second is "we will inspect it instead", which assumes an inspection point that a small branch does not have and that a pinning client would refuse anyway. The third is treating a UDP deny as equivalent to a TCP deny in cost: for TCP the fallback story usually exists, for the pinned QUIC-only agent it does not. ## The sentence that shows judgment Blocking UDP/443 buys you a single carrier that your existing policy already describes. It does not buy you application identity, it charges every user a setup delay, and it converts one class of client from "working but unreadable" into "an exception you own".
- How do you find out what will break before you apply the deny?Count it first. Put the deny in with logging, or use flow records to enumerate which internal hosts currently send to UDP/443 and to which destinations, over a period long enough to include monthly jobs. The list of source hosts is usually short and immediately tells you which are user laptops and which are appliances you cannot change.
- A vendor agent speaks only QUIC and pins its certificate. What are your real options?Permit it, as narrowly as you can — scoped to that agent's source hosts and its known destinations — or lose the function. Inspection is unavailable at any price because the client rejects a substituted certificate, and there is no fallback transport to push it onto. The right move is to make the exception explicit and owned, not to leave a broad UDP/443 permit that covers everything else too.
- Does denying udp/443 tell you anything more about the tcp/443 traffic that remains?No. It removes an alternative carrier; it adds no identification. The remaining TCP flows are exactly as opaque as before, and an honest write-up says so rather than implying that consolidating onto one port improved visibility.
saying these in an interview costs you the question
- Assumes every client falls back to TCP
- Claims blocking UDP/443 improves application visibility
- Plans to inspect a certificate-pinning client instead
- Ignores the setup-delay cost on a high-latency link
- Leaves a broad udp/443 permit instead of a scoped exception