Re: [quicwg/base-drafts] Limit RCID state (#3547)

[Kazuho Oku <[e-mail]>]

@kazuho commented on this pull request.



> @@ -1069,6 +1069,15 @@ to cease using the connection IDs when requested can result in connection
 failures, as the issuing endpoint might be unable to continue using the
 connection IDs with the active connection.
 
+An endpoint SHOULD limit the number of outstanding RETIRE_CONNECTION_ID frames
+to bound the necessary state. In order to allow a peer to retire all previously
+issued connection IDs, the limit on the number of outstanding
+RETIRE_CONNECTION_IDs SHOULD be at least the active_connection_id_limit. An

PS. To avoid the confusion being discussed in the comments right above, I think my preference goes to having something like:

_An adversarial peer can request an endpoint to retain state for an unlimited amount of connection IDs being retired by withholding acknowledgements for the RETIRE_CONNECTION_ID frames, at the same time sending NEW_CONNECTION_ID frames with updated values in the Retire Prior To fields, or probing and discarding paths repeatedly._

_As a mitigation, endpoints SHOULD limit the amount of state that they retain for retiring the connection IDs. In order to allow a well-behaving peer to request retirement of all the previously issued connection IDs while an endpoint waits for some RETIRE_CONNECTION_ID frames to be acknowledged,  an endpoint SHOULD be capable of tracking at least the active_connection_id_limit plus the number of retirements that the endpoint might initiate at one time. When the amount of state required for tracking the connection IDs being retired exceeds that limit, an endpoint MAY close the connection with a CONNECTION_ID_LIMIT_ERROR._

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3547#discussion_r401362644