QUIC (0-RTT)

0-RTT relies on a pre-shared key (PSK) or session ticket established during a prior connection. The client caches this ticket and uses it to derive early data encryption keys. On a subsequent connection, the client sends the encrypted early data alongside the ClientHello, allowing the server to immediately decrypt and process the request without a full TLS handshake. This mechanism is defined in RFC 8446 for TLS 1.3, which QUIC mandates.

A critical security consideration: 0-RTT data is inherently vulnerable to replay attacks. An attacker can capture the encrypted early data and retransmit it, causing the server to process the same request multiple times. Mitigations include:

• Idempotent operations only: Servers must ensure 0-RTT requests (e.g., GET) are safe to replay.
• Single-use tickets: Limiting the number of times a session ticket can be used.
• Client IP validation: Correlating early data with a consistent source address.

For proactive caching and edge pre-fetching, 0-RTT is transformative. When fetching a small, predicted object from a MEC cache, a standard TLS 1.2 handshake requires 2-3 round trips (often 50-150ms on cellular networks) before the first byte of data. 0-RTT collapses this to 0 round trips, meaning the cached content begins arriving at the client within the propagation delay of the first packet. This makes pre-fetching small, dynamic objects viable.

Standard QUIC 1-RTT handshakes provide perfect forward secrecy (PFS) via ephemeral Diffie-Hellman key exchange. 0-RTT data, however, is encrypted using keys derived solely from the static PSK. If the PSK is later compromised, all previously recorded 0-RTT data can be decrypted. This is a fundamental trade-off: latency vs. forward secrecy. Applications handling sensitive data should never transmit non-idempotent or confidential information in 0-RTT early data.

QUIC serves as the transport for HTTP/3. 0-RTT is exposed to web applications via the Early-Data header. A server can indicate support by sending a 103 Early Hints response. Browsers typically restrict 0-RTT to idempotent methods (GET, HEAD, OPTIONS) and may delay sending non-idempotent requests until the handshake completes. This integration allows web pages to load cached assets with zero handshake overhead on repeat visits.

To prevent amplification attacks, QUIC enforces strict limits on 0-RTT. A server must not send more than three times the amount of data it has received from the client until the client's address is validated. This means a server's response to a 0-RTT request is capped in size. For edge caching, this implies that 0-RTT is best suited for fetching small, critical objects (e.g., a JSON manifest or a small image tile) rather than large video segments, which must wait for address validation.

The cryptographic foundation enabling QUIC's 0-RTT. TLS 1.3 allows a client to send application data in its first flight of messages by reusing a Pre-Shared Key (PSK) from a prior session. This eliminates the full handshake round trip. The server accepts or rejects this 'early data' based on PSK validity. A critical security consideration is replay attacks—an attacker could capture and resend the 0-RTT data. Mitigations include limiting 0-RTT to idempotent requests (GET, HEAD) and enforcing strict time-to-live (TTL) on session tickets.

QUIC connections are identified by a Connection ID, not the IP/port tuple. This enables seamless connection migration when a user moves between Wi-Fi and cellular networks. Combined with 0-RTT, a mobile device can switch networks and immediately resume sending cached data without a new handshake. For mobility-aware caching, this means a user handed over to a new base station can fetch pre-placed content from the new edge node without re-establishing a secure session, preserving the latency gains of proactive caching.

QUIC supports multiple independent byte streams within a single connection, eliminating head-of-line (HOL) blocking at the transport layer—a known limitation of TCP. For edge caching, this allows a client to simultaneously request multiple cached objects (e.g., HTML, CSS, JS, images) over one QUIC connection. If one stream experiences packet loss, others proceed unimpeded. This is critical for tile-based caching of 360-degree video, where dozens of spatial tiles must be fetched concurrently to assemble a viewport without visual stutter.

HTTP/3 is the mapping of HTTP semantics over QUIC. It inherits 0-RTT, multiplexing, and connection migration directly from the transport. For MEC caching scenarios, an HTTP/3-capable edge node can serve cached objects with 0-RTT on the first request after a session resumption. The Alt-Svc header allows origin servers to advertise QUIC support, enabling clients to upgrade from TCP to QUIC transparently. This tight integration means any edge cache supporting HTTP/3 automatically benefits from QUIC's latency reductions without application-layer changes.

0-RTT data is vulnerable to replay attacks. Key mitigations include:

• Idempotency enforcement: Only allow safe HTTP methods (GET, HEAD, OPTIONS) in 0-RTT.
• Session ticket rotation: Use single-use or short-lived tickets with the max_early_data_size extension.
• Server-side nonce tracking: Reject duplicate ClientHello messages within a time window.
• Application-layer tokens: Embed a unique, server-generated token in the first request that must be echoed back. For content freshness in caching, replay protection ensures stale or malicious data isn't injected into the cache via replayed 0-RTT requests.

TCP Fast Open (TFO) also enables 0-RTT data, but operates at the TCP layer with a cookie mechanism. QUIC's 0-RTT is more robust because:

• Encryption: QUIC encrypts all data, including transport headers; TFO data is unencrypted until the TLS handshake completes.
• Multiplexing: TFO still suffers from TCP's HOL blocking; QUIC does not.
• Migration: TFO cannot survive IP changes; QUIC's Connection ID enables seamless migration. For backhaul offloading, QUIC's combination of 0-RTT, encryption, and resilience to network changes makes it the superior transport for edge cache retrieval over unreliable last-mile links.