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

[Kazuho Oku <[e-mail]>]

@kazuho commented on this pull request.



> @@ -1069,6 +1069,17 @@ 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 MAY elect to limit the number of outstanding RETIRE_CONNECTION_ID

I think this should be a SHOULD.

In case of a client-driven attack using path probes, an innocent server without this type of bound would end up holding infinite amount of state.

> @@ -1069,6 +1069,17 @@ 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 MAY elect to 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, this limit SHOULD be at least the
+active_connection_id_limit. Within this limit, endpoints SHOULD prioritize
+sending frames which the peer is least likely to have received.
+
+Endpoints SHOULD NOT issue updates of the Retire Prior To field before receiving
+RETIRE_CONNECTION_ID frames for the previous update of Retire Prior To. Doing so
+may result in the peer being unwilling to immediately retire all the connection
+IDs, if retiring them would cause it to exceed its limit on outstanding
+RETIRE_CONNECTION_ID frames, as described above.

I think that the last sentence is inaccurate. As pointed out in my previous comments (https://github.com/quicwg/base-drafts/pull/3547#discussion_r399240482), an endpoint might receive a request to retire all the CIDs while it is already in the process of retiring some. In such case, *just* remembering `max_connection_id_limit` CIDs being retired is insufficient.

I think it would be better if we removed the recommendations from these two paragraphs, so that each of them becomes a problem statement, then in a new paragraph describe some of the measures that an endpoint SHOULD toke; e.g.:
* remember max_connection_id_limit CIDs, and also track those below RPT (as suggested by @ianswett in https://github.com/quicwg/base-drafts/pull/3547#discussion_r399248483)
* remember 2 * max_connection_id_limit

-- 
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#pullrequestreview-383250846