MUST retire Connection IDs becoming stale

[kazuho]

Closes #3046.

@martinthomson:

As discussed, should be that the receiving side will retire within one PTO. The sending side can enforce at 3PTO, by dropping the connection.

The text in the PR adopts 1 PTO as a suggestion, as I am not sure if there is a point in that value being the exact limit. If it needs to be, we can rephrase the text to "MUST retire the corresponding connection IDs in one PTO and send corresponding RETIRE_CONNECTION_ID frames."

[martinthomson]

I think that the most interesting behaviour to specify is at the endpoint that requests retirement. "Endpoints that request that peers retire connection IDs SHOULD be prepared to receive packets that contain connection IDs that they have requested be retired for a period of approximately three times the PTO."

[martinthomson]

Maybe we could even say "approximately", and add "Endpoints that request that peers retire connection IDs SHOULD be prepared to receive packets that contain connection IDs that they have requested be retired for a period of approximately three times the PTO."

[kazuho]

Thank you for the suggestions. I've added "approximately", and merged the other suggestion into the next paragraph. PTAL.

[nibanks]

Looks fine to me. I'm also fine with Martin's suggestions as well.

[ianswett]

LG, but I like @martinthomson suggestion

[erickinnear]

The endpoint here has always been going to do whatever it does, regardless of whether we said SHOULD or MUST, so this seems fine. I do like the direction for the other endpoint to wait 3PTO, that would be nice to include.

[mikkelfj]

I'm a bit worried that a stateless reset from a retired CID could be used as an attack vector by simply delaying packets en-route. However, if the reset is only effective on CIDs that are no longer recognised that shouldn't be a problem.

[MikeBishop]

@mikkelfj, the delayed packets are handled by this text:

Tokens are invalidated when their associated connection ID is retired via a RETIRE_CONNECTION_ID frame (Section 19.16).

An endpoint MUST NOT check for any Stateless Reset Tokens associated with connection IDs it has not used or for connection IDs that have been retired.

If you've followed the requirement to retire as indicated, then a delayed packet triggering stateless reset can't hurt you.