ToppyMicroServices

RFC 8999 Quiz

QUIC invariants and version evolution

πŸ‡ΊπŸ‡ΈπŸ‡―πŸ‡΅
0 / 0

References (URLs)

Q1: What is RFC 8999 primarily trying to preserve?

Multiple Choice
**Explanation:** RFC 8999 fixes only the properties needed to recognize QUIC and negotiate versions. A: copying all of version 1 would prevent meaningful evolution. B: the document protects future deployment by defining what cannot change. C: congestion control is not one of the version-independent properties defined here.

Q2: A field behavior is not fixed or prohibited by RFC 8999. What follows?

Multiple Choice
**Explanation:** The default is freedom to evolve. A: observable v1 behavior is not automatically invariant. B: absence from the invariant set is not a reservation. C: unless RFC 8999 specifically prohibits a change, another QUIC version can define different semantics.

Q3: Which statements belong to RFC 8999's abstract description of QUIC? Select all that apply.

Multi-Select
**Explanation:** A: Connection-oriented endpoint communication is part of the document's abstract model. B: UDP datagrams are the containers exchanged by QUIC endpoints. C: HTTP/3 is one application protocol over QUIC; HTTP semantics are not a version-independent property of QUIC itself. D: The connection is the shared protocol state established between the two endpoints.

Q4: Which header statements are invariant across QUIC versions? Select all that apply.

Multi-Select
**Explanation:** A: The first byte's high bit is the invariant discriminator between long and short headers. B: A short header has a Destination Connection ID after the first byte, but its length is not encoded in that packet. C: The long-header layout exposes Version followed by the length and value of each connection ID. D: Version and Source Connection ID are absent from the invariant short-header layout.

Q5: Which implementation assumption about a QUIC connection ID is safe?

Multiple Choice
**Explanation:** A: RFC 8999 defines the field as opaque. B: each endpoint chooses connection IDs by version-specific methods, and one connection can use different values. C: connection IDs identify delivery context, not a user or authorization subject.

Q6: What does Version 0x00000000 identify?

Multiple Choice
**Explanation:** A: zero is reserved for Version Negotiation and identifies that long-header packet type. B: it is not an insecure form of QUIC v1. C: short headers do not carry a Version field.

Q7: An endpoint receives an unrecognized QUIC packet with a short header. What does RFC 8999 say about version negotiation?

Multiple Choice
**Explanation:** A: only an unsupported long-header version might elicit Version Negotiation. B: the fields have different meanings and the short header has no Version field. C: RFC 8999 explicitly excludes short-header packets as triggers.

Q8: A client receives a plausible Version Negotiation packet and plans to switch versions. What additional condition matters?

Multiple Choice
**Explanation:** Version Negotiation packets have neither integrity nor confidentiality protection. A: a recognizable format is not authentication. B: an endpoint changing version as a result must authenticate the semantic content using the chosen version's mechanism. C: RFC 8999 does not define β€œfirst value wins.”

Q9: What is the most accurate review finding?

Multiple Choice

A network gateway admits a packet as QUIC only when it has the QUIC v1 fixed bit and exposes the TLS-related traits the gateway learned from v1 traffic. A future version keeps every invariant in RFC 8999 but changes both observations, so the gateway blocks it.

**Explanation:** RFC 8999 Section 7 and Appendix A warn that middleboxes can attach v1 semantics to observable traits that are not invariant. A version satisfying the document's fixed properties is not made invalid merely because it changes those traits. C identifies the gateway's ossification. B would let observation silently redefine the protocol contract, while D confuses an opaque routing value with a permanent per-connection constant.

Q10: Which versioning and verification split best meets all requirements?

Multiple Choice

A2A profile 1 exposes task type, grant format, and routing fields. Profile 2 must be able to encrypt or restructure them. Gateways need a stable profile identifier and negotiation exchange for dispatch, while backends must validate the version-specific signed grant before authorizing an operation.

**Explanation:** RFC 8999 Section 2 keeps only the minimum properties needed to recognize QUIC and negotiate versions, leaving other semantics version-specific. Section 7 also requires a version-changing endpoint to authenticate the semantic content of negotiation by a mechanism defined for the chosen version. C applies that separation by analogy and keeps authorization at the component that understands the signed grant. RFC 8999 does not itself define A2A fields or grant validation; those remain obligations of the A2A profiles.