abandoned the handshake without a CONNECTION_CLOSE. It saw the parameter -- that travels in the handshake -- and §7.4 requires treating it as a connection error of type TRANSPORT_PARAMETER_ERROR, which RFC 9000 §10.2 signals in a CONNECTION_CLOSE. None was sent: this client runs on the endpoint's own host, where nothing is lost in transit.
The client did something the clause forbids, or failed to do what it requires.
What was measured
- Client
- lsquic — LiteSpeed lsquic + BoringSSL, 4.9.4 (2b30189)
- Test
- Transport parameter carrying a value the specification forbids —
q-invalid-transport-param - Clause
- RFC 9000 §7.4, §18.2 (MUST)
- Class
- correctness — Rejected something invalid, with the code the RFC names.
- Required behaviour
- Close the connection with TRANSPORT_PARAMETER_ERROR. §18.2 makes an ack_delay_exponent above 20 invalid, and §7.4 is a MUST: "An endpoint MUST treat receipt of a transport parameter with an invalid value as a connection error of type TRANSPORT_PARAMETER_ERROR." Distinct from a *duplicate* parameter, which the same clause makes only a SHOULD — this port sends one parameter, once, with a value outside its permitted range. The parameter travels in the handshake, so every client that connects here reads it. Only a client that answers with a CONNECTION_CLOSE this endpoint can read is scored: one that simply abandons the handshake is recorded as inconclusive, because a close that was sent and lost looks exactly like one that was never sent.
- Measured
- 2026-10-27
Reproduce it
The suite is the judge, so the reproduction is to point the same client at the same test and let the server report what it saw.
SESSION=$(curl -sX POST https://conformance.pqcrypta.com/session | jq -r .id)
# then drive lsquic at the test URL and read the verdict:
curl -s https://conformance.pqcrypta.com/report/$SESSION.json | jq '.results["q-invalid-transport-param"]'