The draft doesn't currently discuss Stateless Resets at all.
When using vanilla CONNECT-UDP, each client has a dedicated origin-facing port. If the origin sends a Stateless Reset, it will be forwarded naively, parsed by the client, and the client will close the stream as it is no longer needed. (Or the client could start a new connection using the same tunnel; doesn't matter to the proxy.)
When using forwarding mode, the proxy will reject Stateless Reset packets as they do not match any open request's registered CIDs. The client doesn't learn that the connection has failed and will continue to send packets, which the origin will continue to reject, until the connection eventually times out.
Should we consider having the client provide Stateless Reset tokens to the server alongside the CIDs? In that case, the proxy could either correctly relay Stateless Reset packets or convert them to stream error(s) for the affected CID.
The draft doesn't currently discuss Stateless Resets at all.
When using vanilla CONNECT-UDP, each client has a dedicated origin-facing port. If the origin sends a Stateless Reset, it will be forwarded naively, parsed by the client, and the client will close the stream as it is no longer needed. (Or the client could start a new connection using the same tunnel; doesn't matter to the proxy.)
When using forwarding mode, the proxy will reject Stateless Reset packets as they do not match any open request's registered CIDs. The client doesn't learn that the connection has failed and will continue to send packets, which the origin will continue to reject, until the connection eventually times out.
Should we consider having the client provide Stateless Reset tokens to the server alongside the CIDs? In that case, the proxy could either correctly relay Stateless Reset packets or convert them to stream error(s) for the affected CID.