General technical interview: How does QUIC survive a network change?

Prompt and context

A mobile client is downloading a large file when it switches from Wi-Fi to cellular, changing its source IP and UDP port. Explain how QUIC connection migration identifies the same connection, when migration is allowed, how a new path is validated, and how failure protects the connection and server resources.

What the interviewer evaluates

• Whether you separate a connection identifier from the network address instead of treating a four-tuple change as a new connection.
• Whether you explain handshake confirmation, path validation, PATH_CHALLENGE, and PATH_RESPONSE in order.
• Whether you handle NAT rebinding, Connection ID exhaustion, disabled migration, and abusive probing.
• Whether you discuss privacy, congestion control, billing, and observability trade-offs.

Clarifying questions

1. Did the client intentionally switch networks, or did a NAT only change its external port?
2. Is the handshake confirmed, and did the server set disable_active_migration?
3. Can the product tolerate brief retransmission and path-probing overhead?
4. Must the design reduce linkability across network addresses?
5. If the new path fails validation, should the client keep the old path or reconnect?

30-second answer

QUIC uses a Connection ID to associate connection state rather than requiring a stable source IP and port. After handshake confirmation, the client probes from the new address; the server validates reachability with PATH_CHALLENGE and PATH_RESPONSE before normal data is sent. NAT rebinding can be handled on the existing connection, but active migration is constrained by transport parameters. On failure, retain the old path or reconnect while bounding state and amplification on an unvalidated address.

Deep-dive answer

Step 1: Separate state from addresses

TLS, streams, and congestion state belong to the QUIC connection; IP and UDP addresses describe a path. A Connection ID lets the server find connection state after an address change. Without a suitable non-zero-length ID, migration and path probing are constrained. A load balancer must route by Connection ID, not only by a five-tuple hash.

Step 2: Confirm when migration is allowed

An endpoint must not actively migrate before the handshake is confirmed. After a local address change, the client may probe the new path. If the server advertises disable_active_migration, the client cannot actively send ordinary packets from a different address unless it uses a server-provided preferred address. This avoids treating an unconfirmed address as a trusted path.

Step 3: Perform path validation

The new address first sends packets containing probing frames, and the server returns PATH_RESPONSE. Success shows that the peer can receive and return traffic on the path; failure only says that path is unusable and should not terminate a connection that still has a valid path. Set probe timeouts, retry limits, and a state budget for unvalidated paths.

Step 4: Handle NAT rebinding

A NAT can replace the client’s external port after idle time. The server sees an address change but still receives packets with a valid Connection ID. Validate the new path before updating path state; do not require a new handshake for every port change. Bound the rate and state for frequent changes so an attacker cannot consume probe resources.

Step 5: Protect congestion and amplification boundaries

Reusing the old congestion context after migration may not match the new path. Follow QUIC recovery behavior and measurements for congestion window, loss, and RTT. The server must not send large amounts of non-probing data to an unvalidated address, limiting UDP amplification. Keep the old path until the new path has evidence of reachability.

Step 6: Consider privacy and linkability

The same Connection ID helps the server correlate an address change, but an observer might also correlate user activity. The client can rotate to a new Connection ID and avoid predictable address changes. Servers must follow Connection ID lifetime and encryption requirements; a public ID is not a user identity.

Step 7: Define fallback and observability

Record path-validation success, probe RTT, interruption time, old-path keepalive, Connection ID inventory, loss, and reconnect rate. On validation failure, keep the old path and use exponential backoff. If no path remains valid, close or reconnect. Exercise Wi-Fi handoff, NAT rebinding, disabled migration, and abusive probing.

Model answer

I would separate QUIC connection state from address paths: the Connection ID lets the server identify the connection after the client IP or port changes. After handshake confirmation, the client sends PATH_CHALLENGE from the new address and marks the path usable only after receiving PATH_RESPONSE; it keeps the old path and bounds state and sending on the unvalidated path during this process. NAT rebinding can reuse the connection after validating the new port. If disable_active_migration is set, active migration is not allowed. Load balancers must support Connection ID routing; privacy-sensitive clients rotate IDs. Monitor validation success, interruption, probe RTT, loss, and reconnects, then fall back or reconnect when validation fails.

Common mistakes

• Binding QUIC to source IP and port and creating a new connection on every network change.
• Actively migrating before handshake confirmation or sending large data before path validation.
• Treating NAT rebinding as a protocol error and requiring a handshake for every port change.
• Ignoring disable_active_migration and the server preferred-address rules.
• Reusing old RTT, loss, and congestion assumptions after migration.
• Using predictable Connection IDs or routing only by a five-tuple hash.

Follow-up questions

Follow-up 1: Why is a Connection ID alone insufficient to trust a path?

It associates connection state but does not prove that the peer is reachable at the new address. A challenge and response validate the return path before significant traffic is sent.

Follow-up 2: Does failed validation destroy the connection?

No, if the old path remains valid. Failure means the new path is unusable; keep or probe the old path and close only when no usable path remains.

Follow-up 3: Why limit sends to an unvalidated address?

An attacker could spoof an address and induce amplification. Limit an unvalidated path to controlled probing and state; increase the budget only after validation.

Follow-up 4: Must the congestion window be reset after migration?

There is no universal reset based only on an address change. The new path may have different RTT, bandwidth, and loss, so follow QUIC recovery behavior and measurements rather than assuming either old conditions or zero capacity.

Follow-up 5: How can migration reduce observer linkability?

Rotate Connection IDs reasonably and avoid predictable patterns while preserving server routing and state management. A Connection ID is not an identity credential.

Follow-up 6: What must a load balancer change?

It must route packets before and after migration using the encrypted Connection ID or an equivalent connection-aware mechanism to the server holding the state; an address change must not be treated as a new session.