1. Prompt
A mobile client is downloading a large file over HTTP/3. The user switches from Wi-Fi to cellular, changing the client's source IP and UDP source port. The product wants the download to continue without a complete new connection establishment.
Explain how QUIC recognizes packets as belonging to the same connection, describe validation when the connection moves to a new path, and distinguish NAT rebinding, client-initiated migration, and server migration. Discuss the effects on load balancing, state management, amplification defense, observability, and privacy.
2. Constraints and clarifications
- Discuss RFC 9000 transport semantics; HTTP/3 is the application carried over QUIC and does not change path-validation rules.
- The client and server completed the handshake, and the client has usable spare connection IDs. If the server provides only zero-length connection IDs, deployment constraints limit migration.
- “Keeping the connection” does not mean every packet on the old path remains reachable. A path change can cause loss, reordering, or fresh congestion probing.
- Do not implement a complete QUIC stack. Focus on state transitions, attack surfaces, and observable diagnostic signals.
3. Core mechanism: connection IDs are independent of the four-tuple
TCP usually locates a connection with local address, remote address, local port, and remote port. A mobile-network switch changes that four-tuple. After the handshake, QUIC uses a Destination Connection ID (DCID) and Source Connection ID (SCID) to map packets to connection state, so a new path can carry the same connection identity.
Endpoints generate connection IDs and provide them with NEWCONNECTIONID frames. They also track sequence numbers, reset tokens, and the number of available IDs; an old ID can be retired with RETIRECONNECTIONID. A connection ID should not directly encode a user's IP, account, or inferable stable identity because that increases linkability and privacy risk.
4. Migration and path-validation flow
After detecting a source-address change, a client can send on the new path with a spare DCID and include a PATHCHALLENGE. The server returns a PATHRESPONSE on the new path, allowing the client to confirm that the peer can receive and return traffic there. Before validation, endpoints must cap data sent to the new address so a spoofed address cannot induce amplification.
on_packet(packet, source_address):
conn = lookup_by_destination_connection_id(packet.dcid)
if conn is unknown:
reject_or_handle_as_new_connection()
elif source_address == conn.validated_path:
process_with_current_congestion_state()
else:
mark_possible_new_path(source_address)
send_path_challenge_on_new_path()
cap_bytes_sent_until_validation()
on_path_response(token, source_address):
if token matches outstanding_challenge:
conn.validated_path = source_address
switch_active_path()
update_congestion_and_rtt_measurement()Path validation proves that packets can make a round trip; it does not prove that the address belongs to a particular user or that the old path is dead. An implementation must handle old and new paths coexisting, reordered responses, duplicate challenges, timeouts, and validation failure.
5. Three cases and system impact
NAT rebinding occurs when an intermediary changes an external port or mapping, and the endpoint may observe the change passively. RFC behavior allows an endpoint to continue a connection under the specified conditions instead of treating every port change as client-initiated migration; the implementation still validates the path and remeasures RTT and congestion state.
Client-initiated migration commonly follows an interface switch: the client selects a spare connection ID and sends from the new address. Server migration is constrained by protocol rules and implementation support; a server changing its egress IP is not simply a symmetric operation. Rotating connection IDs can reduce correlation between paths, but logging and risk systems need a controlled connection reference to relate the same session.
A load balancer must route a connection by DCID to a backend that can recover its state, or use shared state for encrypted handshake and transport state. Five-tuple stickiness alone breaks when the address changes. Observability should record path-validation outcomes, migration counts, old and new RTT, loss, retransmission, and connection-ID lifetimes without logging unprotected user identifiers.
6. Follow-ups and traps
- Why not accept any new address directly? An attacker could spoof a source address and make the server send a large response to a victim; validation and send limits reduce amplification risk.
- Is a connection ID a permanent identity? No. Endpoints can rotate and retire IDs and limit their lifetime; applications should not use them as user identity or cross-connection tracking keys.
- Does migration keep all congestion state? Not blindly. The new path may have different capacity and RTT, so it needs probing and burst control. An implementation may conservatively reuse some state but needs validation and fallback.
- Can a proxy or layer-four load balancer break migration? If it terminates QUIC, rewrites DCIDs, or cannot route the new path to the original backend, migration can fall back to a new connection. Deployment must define CID encoding, state ownership, and health transfer.
7. Verification and debugging checklist
- Align packets: Correlate handshake DCID/SCID,
NEWCONNECTIONID,PATHCHALLENGE, andPATHRESPONSEto verify that both paths map to one connection. - Inject network changes: Switch interfaces, trigger a NAT-port change, delay or drop validation responses, and observe rate limits, retries, and fallback.
- Check routing and state: Compare DCID routing, backend connection tables, and retired-ID records; confirm the system does not rely only on the old four-tuple.
- Check security signals: Track unknown DCIDs, validation failures, anomalous migration rates, and amplification byte ratios instead of treating attack traffic as ordinary mobility.
8. Interview scoring points
Can explain connection IDs versus the four-tuple
The candidate should explain why an address change breaks the TCP four-tuple and how QUIC uses DCID/SCID to recover connection state.
Can explain path validation and amplification defense
They should mention PATHCHALLENGE, PATHRESPONSE, send limits, old/new path coexistence, and fallback after validation failure.
Can distinguish migration, rebinding, and deployment boundaries
They should distinguish NAT rebinding from active migration and cover load balancing, proxy termination, shared state, and ID rotation.
Can propose verifiable debugging
They should propose packet analysis, network-fault injection, DCID-route checks, and security metrics rather than only saying “QUIC runs over UDP, so it is faster.”