In this module, we're going to look at how we can troubleshoot the QUIC protocol,
which will help as we begin to support it in our own environments.
So let's take a look at our outline for this module.
We're going to start off by looking at some common problems with QUIC,
and those include version and compatibility issues and also problems
with firewall and network infrastructure support.
Next,
we'll check out some specific tools that we can use
for testing and validating QUIC, which include online and browser‑based tools,
as well as some command‑line tools.
Last, we'll take a look at some demonstrations of these tools,
first, with some online and browser‑based tools to test QUIC support,
and then last,
we'll dig back into the packets with Wireshark and learn some
additional troubleshooting tips with QUIC.
So first,
let's take a look at some common issues that come up when implementing
and using QUIC, as well as some considerations that we should have in
mind going forward. At this stage of the game, with so many QUIC
versions in play on the internet,
it's possible that we could have a client that supports one
version of QUIC and a server that supports another.
If this is the case, QUIC will not connect,
and it should default back to TCP for most applications,
or at least, at this point in time.
Now, the developers of QUIC knew that this would be the
case as browsers and mobile applications begin to support
this new transport protocol.
So as versions of QUIC further develop,
we can run into cases where clients and servers are not up to speed on
the latest versions, and this is often why servers will advertise more
than one version for a client to use.
If the client can support any of these versions,
then the connection will proceed.
Another area we can run into problems when implementing QUIC
is with infrastructure devices along the network path and
also security detection systems.
Now, at the endpoints,
a ton of work has gone into browsers and servers to process UDP port 80 or 443
as QUIC traffic, but the network has struggled to keep pace.
QUIC is designed from the foundation to be secure from the transport layer up,
which makes it difficult to inspect.
Remember that up until recently, there were few major
services running over secure UDP.
So firewalls, for example,
may not expect applications other than DNS or VoIP to use UDP and may not be
happy with the inability to inspect the encrypted data. In sensitive
environments, this traffic could be dropped altogether.
Now, the same is true for IDS systems.
These have been born and bred to deal with TLS and TCP flows,
but they might not be fully up to speed yet on QUIC,
which could present some alerts.
Also,
we have VPN concentrators, WAN accelerators, and other middle boxes,
which have been tuned to handle TCP for decades, but might not yet know
what to do with QUIC, and network address translation boxes might time
UDP connections differently than TCP,
which could result in a premature rebind. And last, on the
server side, in the data center, cloud or not,
load balancers are going to need to learn how to
distribute QUIC to the front end,
which is a big shift from how they've been doing things with TCP.
So these are just a few of the pain points that we could run
into when implementing and supporting QUIC,
which makes validation prior to a formal rollout even more important.
But how? How can we test QUIC?