ToppyMicroServices

RFC 9000 Quiz

QUIC transport fundamentals

🇺🇸 🇯🇵
0 / 0

References (URLs)

Q1: What is QUIC at a high level

Multiple Choice
**Explanation:** transport, multiplexed, secure, UDP. QUIC provides streams and reliability features with integrated security. QUIC is a transport protocol that uses UDP as its substrate, supports multiplexed streams, and integrates TLS 1.3 style security. - A (incorrect): QUIC is a distinct transport over UDP, not an extension negotiated inside TCP. - B (correct): This matches the RFC 9000 description. - C (incorrect): QUIC uses UDP datagrams but adds secure connection state, reliable streams, loss recovery, and congestion control. HTTP/3 uses QUIC as its transport.

Q2: What is a primary purpose of a QUIC connection ID

Multiple Choice
A QUIC connection ID lets the connection survive path changes because the transport is not identified only by the old IP:port tuple.
Old path IP:port A New path IP:port B Same QUIC connection ID not tied to one path continue connection Server keeps same connection
**Explanation:** connection ID, migration. A connection ID helps identify a connection independently of the IP and port tuple. Connection IDs help keep a connection stable even when the network path changes and can also support load balancing. - A (correct): This enables mobility and smoother handoffs. - B (incorrect): Certificates and authentication are part of TLS, not connection ID. - C (incorrect): URIs belong to application protocols like HTTP, not to transport identifiers. Some deployments use connection IDs to route packets through load balancers without exposing client addresses.

Q3: A packet carrying bytes for stream 4 is lost. Later packets carrying data for streams 8 and 12 arrive. Which receiver behavior matches QUIC stream ordering

Multiple Choice
**Explanation:** RFC 9000 Section 2 defines a QUIC stream as an ordered sequence of bytes, but QUIC does not define an ordering between bytes on different streams. Loss on stream 4 prevents delivery past that stream's gap, while independently received data on streams 8 and 12 can still be delivered. - A (incorrect): QUIC has no connection-wide byte order that requires streams 8 and 12 to wait for stream 4. - B (incorrect): Bytes within stream 4 remain ordered, so data after its gap cannot be delivered first; other streams need not wait. - C (correct): This preserves ordering within stream 4 without imposing that ordering on streams 8 and 12. A byte gap on stream 4 does not impose in-order delivery blocking on streams 8 and 12, although congestion control can still affect the connection as a whole.

Q4: Which credit update addresses the reported block?

Multiple Choice

A sender has reached the advertised offset limit on stream 8 and emits STREAM_DATA_BLOCKED. The connection-wide MAX_DATA limit still has ample credit, and the receiving application has consumed more bytes from stream 8.

**Explanation:** A: Connection credit is not the exhausted limit, so increasing it alone leaves stream 8 blocked. B: RFC 9000 Section 4.1 defines separate stream and connection limits. MAX_STREAM_DATA raises the absolute offset allowed on the identified stream. C: A smaller advertised limit has no effect; senders ignore updates that do not increase the limit. D: WINDOW_UPDATE belongs to HTTP/2. QUIC uses MAX_STREAM_DATA and MAX_DATA frames. Decision rule: Diagnose the exhausted limit before granting credit; stream credit and connection credit solve different receiver-capacity constraints.

Q5: How should the server handle the new client address?

Multiple Choice

After the handshake is confirmed, a server receives a successfully protected non-probing packet for the existing connection from a new client IP:port tuple, consistent with NAT rebinding. That address has not previously been validated.

**Explanation:** A: Authentic packet protection associates the packet with the connection, but RFC 9000 Section 8.2 requires a matching PATH_RESPONSE to prove reachability for the new path. B: Section 9 explicitly supports migration and requires path validation after a peer-address change unless that address was already validated. C: Sections 8.2 and 9.3 support this sequence. The recipient can respond on the new path while respecting migration and anti-amplification rules, and it must start validation if none is underway. D: Section 8.2.3 says an ACK is not adequate path validation because it can be spoofed; the unpredictable PATH_CHALLENGE value must be returned. Decision rule: A valid connection packet can trigger migration handling, but only the path-validation exchange establishes reachability for the new address pair.

Q6: Which security review conclusion stays within RFC 9000's guarantees?

Multiple Choice

An A2A gateway authenticates an agent when a QUIC connection starts, but stores the source IP address as the authorization principal. The connection later migrates, path validation succeeds for a new address, and the gateway plans to authorize privileged requests because the QUIC connection ID is unchanged.

**Explanation:** A: RFC 9000 Section 8.2 validates reachability of an address pair; it does not define the application principal behind that address. B: Section 9 permits connection migration. RFC 9000 does not require application authorization to use the first source address. C: This keeps the transport guarantee and the application decision distinct. The authenticated session can continue while authorization uses evidence designed for principal identity. D: Connection IDs support routing and continuity and can reduce linkability; rotating one is not application re-authentication. Decision rule: RFC 9000 Sections 8.2 and 9 establish path and connection properties. They neither require IP-based authorization nor decide which application identity model to adopt.