Full-conn TP decode failure should close with TRANSPORT_PARAMETER_ERROR #616
Description
In the full-conn path, a transport parameter decode failure (e.g., non-empty value for a zero-length TP like reset_stream_at) currently results in a generic/internal error close rather than TRANSPORT_PARAMETER_ERROR.
RFC 9000 requirement:
- Transport Parameters section: "An endpoint MUST treat receipt of a transport parameter with an invalid value as a connection error of type TRANSPORT_PARAMETER_ERROR."
- For zero-length transport parameters, any non-empty value is invalid, so RFC 9000 applies.
Details:
- lsquic_tp_decode() rejects non-empty values for zero-length TPs via EXPECT_LEN(0).
- In full-conn, when TP parsing fails, esfi_get_peer_transport_params() returns NULL.
- handshake_ok() detects NULL and ABORT_WARN("could not get transport parameters"), which ultimately closes with TEC_INTERNAL_ERROR (no explicit ifc_error set).
Suggested fix: when TP decode fails for full-conn, set ifc_error = TEC_TRANSPORT_PARAMETER_ERROR (e.g., in get_peer_transport_params() or handshake_ok()).
Analysis performed by Codex.
Files:
- src/liblsquic/lsquic_enc_sess_ietf.c (get_peer_transport_params)
- src/liblsquic/lsquic_full_conn_ietf.c (handshake_ok error path)
- src/liblsquic/lsquic_trans_params.c (EXPECT_LEN(0) for reset_stream_at, grease_quic_bit, disable_active_migration)